-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Not compatible with v2 of the Signal REST API #573
Comments
Isn't this a different thing? The original signal stuff is built around https://gitlab.com/morph027/signal-cli-dbus-rest-api which has been super-seeded by https://gitlab.com/morph027/python-signal-cli-rest-api where we read ;)
Still, this docker stuff: is that built around this JSON-RPC of signal-cli, or this an (then perhaps obsolete) addon? Currently I am using that I am not the maintainer of this package, but using Signal with the twofactor gateway. |
At https://gitlab.com/morph027/python-signal-cli-rest-api it is written: So, my attempts are to use bbernhard's signal-cli API implementation https://github.com/bbernhard/signal-cli-rest-api.
So, it takes the variable of the registered account from config.php, eg |
Could you please provide your code as a pull-request? Otherwise it is difficult to see the differences. Once comment at this point in time: hard-coding the number is not necessary (but see my pull request #575, the current code base is unfortunately broken). Still: you are trying to use a package that has nothing to do with the REST-API the signal 2fa gateway has been written for. So this issue is more about supporting another REST API provider, and not about changing the version of the current API. Also, as morph027 states, it is no longer necessary to use an additional REST API wrapper, as signal-cli can do this by itself. So me feeling here is that one should rewrite the Signal tfa provider to talk to signal-cli directly. BTW, morph027 provides a Python client which can be used for testing here: |
Actually, that morh027 is not quite correct here. signal-cli itself provides a non-HTTP JSON RPC daemon mode via stdin/stdout or network sockets. |
Ooopps. YES: signal-cli itself DOES provide an HTTP transport for its JSON RPC stuff: So my suggestion would then to support that, and do not rely an yet another third party library. I probably will provide a pull request later. |
I hava placed a PR which by default uses the native Signal-Cli HTTP endpoint and falls back to morph027 / bbernhard if that is not available. FYI, the needed sending account is added to the Signal gateway configuration and NOT hard-coded as a constant. I did not test that bbernhard Docker thing, could you please test it? Thanks! |
Hi! Please, advise how to test it? Please, send the instructions. |
Well, you need to checkout the app from git, apply my PR, build the app ... all this inside a Nextcloud installation. |
Hi! Sorry for so late question. Have you already applied your PR or are you still waiting for testing from my side? |
Hi! I am migrating to the updated version of the Signal CLI REST API by bbernhard, which has deprecated the v1/send option.
Would you be so kind to upgrade the code according to the swagger provided in https://bbernhard.github.io/signal-cli-rest-api/? See also the examples at https://github.com/bbernhard/signal-cli-rest-api/blob/master/doc/EXAMPLES.md.
In particular, to rework
curl -d '{"message": "foo"}' http://127.0.0.1/v1/send/<recipient_number>
into
curl -X POST -H "Content-Type: application/json" -d '{"message": "<message>", "number": "<my_number>", "recipients": ["<recipient_number>"]}' 'http://127.0.0.1/v2/send
.Or advise how to patch it myself.
UPD:
What I've managed to do quickly:
The question, how to reuse the environmental of exported in docker phone number SIGNAL_CLI_DBUS_REST_API_ACCOUNT to use it instead of hardcoded <my_number>?
The text was updated successfully, but these errors were encountered: