Handle Registration/Link via Dbus?

[bublath]

I digged a bit thru the code to potentially implement a registration via Dbus. However there seems to be a hen-and-egg problem here.
Starting the application in Dbus mode requires a valid registration and getting a RegistrationManager from a Manager is also not straight forward.
Having registration via Dbus would create the possibility to guide users conveniently through the registration process, even potentially embedding the Captcha and redirecting the Captcha by creating a protocal handler to catch the signalcaptcha:// code.
Same for the "link" where the qrcode could be put on the screen.
All this would require to start signal-cli in an unregistered mode, so it would listen to dbus commands (but typically reply with a kind "not registered" exception). What would be the complexity of this?

[bublath]

@AsamK : Before digging into the code more, can this work:

• When starting up, check for valid registry
• If not present in daemon mode, instanciate RegistrationManager instead of Manager (or ProvisioningManager - can we merge them?)
• While not registered, block all dbus commands that require it, basically we only allow isRegistered, register, verify, captcha, link and setNumber
• I would prefer to even set the number dynamically, since that will allow a generic daemon installation (more below)
• Once registration is complete, either simply exit (systemd will restart it automatically) or delete the old manager and create the normal one

The beauty of this would be to provide a standard installation (e.g. a Debian package) that installs a generic signal-cli daemon). That would increase usability significantly. It would also take care about the platform dependency (provide x64 and arm packages) and package dependencies (e.g. the right Java version).
The client programs can then use the methods to guide the users thru the registration process in a user friendly way, which includes guiding them to the Captcha page or displaying the qrcode
By being able to set the number, it would even be possible to switch between profiles on-the-fly and register additional numbers (not sure about the use case, but still nice)

Sounds feasible?

[AsamK]

It's now in master (8f781c0)

[bublath]

Thanks. I'm currently looking into it. I worked on another (non-IT) project during the summer but now I probably can do some coding again.
First thing I noticed: It might make sense to implement the "isRegistered()" method with "false" for the DbusSignalControlImpl class, so the client can determine without an error which interface he is using (could be seen from the object path or doing an introspective as well, but this feels cleaner and easier).
I'll add a pull request once I did some more checking in case I have more change ideas. Let me know before you bump the version, so I can get that in :)

[bublath]

One thing I found is that providing a nonsense number (starting with + but e.g. +000000000000) is creating a rather cryptic reply:
NonSuccessfulResponseCodeException [400] Bad response: 400
I would expect an InvalidNumberException instead.

[bublath]

Correction, I just fetched the latest commits and now I get:
Error Executing Method org.asamk.Signal.register: null

[bublath]

Number check works great with latest commit.
However I now fail to register. When I submit with incorrect or expired captcha, I get an error.
After I submitted a hopefully correct one, signal-cli freezes. Syslog shows in constant repeats:
Aug 31 00:21:32 raspi400 signal-cli[23898]: WARN DaemonCommand - Receiving messages failed, retrying Aug 31 00:21:32 raspi400 signal-cli[23898]: java.io.IOException: Connection closed! Aug 31 00:21:32 raspi400 signal-cli[23898]: #011at org.whispersystems.signalservice.internal.websocket.WebSocketConnection.readRequest(WebSocketConnection.java:191) Aug 31 00:21:32 raspi400 signal-cli[23898]: #011at org.whispersystems.signalservice.api.SignalWebSocket.readOrEmpty(SignalWebSocket.java:244) Aug 31 00:21:32 raspi400 signal-cli[23898]: #011at org.asamk.signal.manager.Manager.receiveMessages(Manager.java:876) Aug 31 00:21:32 raspi400 signal-cli[23898]: #011at org.asamk.signal.commands.DaemonCommand.lambda$run$1(DaemonCommand.java:133) Aug 31 00:21:32 raspi400 signal-cli[23898]: #011at java.base/java.lang.Thread.run(Thread.java:829)

[bublath]

I believe I figured out the problem that caused a hang. My code simply had a glitch when a DBus call does not return data (void function).
Got a successful call with a verification code and saw no error (not sure what caused the error mentioned above last time)
Calling it a day and hope to complete with implementing the verification tomorrow to see if the flow works all the way.

[bublath]

@AsamK I basically finished ny implementation and everrhing from register over captcha (fully automated on a Windows client thanks to the hint I got from @Florian7843 ) to verify is working. I would still appreciate to merge my small PR.
Great work. I'm still polishing my code a bit and plan to release a beta once the next version is bumped.
Now it would also be neat to think about providing apt packages that install with the dbus service in registration mode