Open ostasevych opened 1 year ago
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 ;)
This project is not actively maintained anymore as signal-cli is now offering a native JSON-RPC api via HTTP.
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 python-signal-cli-rest-api
via the patch contained here: #574
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: This project is not actively maintained anymore as signal-cli is now offering a native JSON-RPC api via HTTP.
So, my attempts are to use bbernhard's signal-cli API implementation https://github.com/bbernhard/signal-cli-rest-api. What I've done:
SIGNAL_CLI_DBUS_REST_API_ACCOUNT
in the config.php
public function send()
to be compatible with the API v2, which is the only in the bberhnard's code (API v1 has been completely removed) at lib/Service/Gateway/Gateway.php
:
<?php
declare(strict_types=1);
/**
*/
namespace OCA\TwoFactorGateway\Service\Gateway\Signal;
use OCA\TwoFactorGateway\Exception\SmsTransmissionException; use OCA\TwoFactorGateway\Service\Gateway\IGateway; use OCA\TwoFactorGateway\Service\Gateway\IGatewayConfig; use OCP\Http\Client\IClientService; use OCP\ILogger; use OCP\IUser;
// added to get SystemValue: use OCP\IConfig;
/**
An integration of https://github.com/bbernhard/signal-cli-rest-api with back deprecated compatibility of https://gitlab.com/morph027/signal-web-gateway */ class Gateway implements IGateway {
/** @var IClientService */
private $clientService;
/** @var GatewayConfig */
private $config;
/** @var ILogger */
private $logger;
public function __construct(IClientService $clientService,
GatewayConfig $config,
ILogger $logger,
// added to get SystemValue: IConfig $config2) { $this->clientService = $clientService; $this->config = $config; $this->logger = $logger; // added to get SystemValue: $this->config2 = $config2; } /**
2023-06-18 patched by OS: added the system variable of the registered number/account SIGNAL_CLI_DBUS_REST_API_ACCOUNT, modified send function */ public function send(IUser $user, string $identifier, string $message) { $client = $this->clientService->newClient(); // determine type of gateway $response = $client->get($this->config->getUrl() . '/v1/about'); if ($response->getStatusCode() === 200) { // new v2 style gateway https://github.com/bbernhard/signal-cli-rest-api $recipient_acct = [$identifier]; $registered_acct = $this->config2->getSystemValue('SIGNAL_CLI_DBUS_REST_API_ACCOUNT',''); $response = $client->post( $this->config->getUrl() . '/v2/send', [ 'json' => [ 'message' => $message, 'number' => $registered_acct, 'recipients' => $recipient_acct ],
]
);
$body = $response->getBody();
$json = json_decode($body, true);
if ($response->getStatusCode() !== 201 || is_null($json) || !is_array($json) || !isset($json['timestamp'])) {
$status = $response->getStatusCode();
throw new SmsTransmissionException("error reported by Signal gateway, status=$status, body=$body}");
}
}
else {
// Try old deprecated gateway https://gitlab.com/morph027/signal-web-gateway
$response = $client->post(
$this->config->getUrl() . '/v1/send/' . $identifier,
[
'body' => [
'to' => $identifier,
'message' => $message,
],
'json' => [ 'message' => $message ],
]
);
$body = $response->getBody();
$json = json_decode($body, true);
if ($response->getStatusCode() !== 200 || is_null($json) || !is_array($json) || !isset($json['success']) || $json['success'] !== true) {
$status = $response->getStatusCode();
throw new SmsTransmissionException("error reported by Signal gateway, status=$status, body=$body}");
}
}
}
/**
So, it takes the variable of the registered account from config.php, eg SIGNAL_CLI_DBUS_REST_API_ACCOUNT = '+380941112233' and uses to send the auth messages. A bit dirty hack, but works for me. Please, correct where needed.
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:
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!
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.
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? Would you be so kind to send the link to your PR?
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>
intocurl -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?