Skip to content
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

Looks like the examples are not doing anything at all #3

Closed
boredomwontgetus opened this issue Feb 28, 2022 · 13 comments
Closed

Looks like the examples are not doing anything at all #3

boredomwontgetus opened this issue Feb 28, 2022 · 13 comments

Comments

@boredomwontgetus
Copy link

Hi!

I seem to be unable to even get your examples to work.

I am running this version of the api container:

$ curl -X GET "http://bla.foo.net:8091/v1/about" -H "accept: application/json"
{"versions":["v1","v2"],"build":2,"mode":"json-rpc","version":"0.56"}%  

Took me a while to find out i have to use json-rpc to get this working at all.
But now - just simply - running your example bot.py nothing ever happens no matter what i send to the group in question.

SIGNAL_SERVICE=bla.foo.net:8091 PHONE_NUMBER="+40123456789" GROUP_ID="group.blV5OVZkUjBqSWlxT02304234kladjfklaejrT0=" GROUP_SECRET="dasfasdfawefadfaseGOlDY=" python3 bot.py
WARNING:root:[Bot] Could not initialize Redis. In-memory storage will be used. Restarting will delete the storage!

I changed all private information in that in-/outputs.

Everything works as expected when testing with wscat.

Thanks in advance.

@filipre
Copy link
Owner

filipre commented Mar 1, 2022

Hi, thank you for your report. I was able to reproduce the issue with version 0.56. In fact, when receiving messages, I got back this error instead:

"Number not registered with JSON-RPC"

I have to investigate what's up with that and probably reach out to signal-cli-rest-api or signal-cli directly. You mentioned that everything worked as expected with wscat. Does this include receiving messages and sending them? If that is the case, the issue is probably somewhere when creating the websocket connection. However, the error above indicates that something before breaks already.

I tried 0.53 (as specified in the docker-compose.yml in the example folder) and for this version, everything seems to work. Nevertheless, I changed the logging level to INFO to debug a bit more. Please pull the example folder again. This is my output:

Signal Chat

command_1

API:

...
signal-cli-rest-api_1  | time="2022-03-01T19:13:12Z" level=info msg="Started Signal Messenger REST API"
signal-cli-rest-api_1  | [GIN] 2022/03/01 - 19:13:41 | 201 |    418.6902ms |      172.28.0.1 | POST     "/v2/send"

Bot:

WARNING:root:[Bot] Could not initialize Redis. In-memory storage will be used. Restarting will delete the storage!
INFO:apscheduler.scheduler:Scheduler started
INFO:root:[Bot] Producer #1 started
INFO:root:[Bot] Consumer #1 started
INFO:root:[Bot] Consumer #2 started
INFO:root:[Bot] Consumer #3 started
INFO:root:[Raw Message] {"envelope":{"source":"+49123456789","sourceNumber":"+49123456789","sourceUuid":"aaaaaaaa-bbea-4a42-adf9-aaaaaaaaa","sourceName":"René","sourceDevice":1,"timestamp":123456789,"syncMessage":{"sentMessage":{"timestamp":123456789,"message":"command_1","expiresInSeconds":0,"viewOnce":false,"mentions":[],"attachments":[],"contacts":[],"groupInfo":{"groupId":"asdf=","type":"DELIVER"},"destination":null,"destinationNumber":null,"destinationUuid":null}}}}
INFO:root:[Bot] Consumer #1 got new job in 0.00055 seconds
INFO:root:[Bot] Consumer #1 got new job in 0.00260 seconds
INFO:root:[Bot] Consumer #1 got new job in 0.00286 seconds
INFO:root:[Bot] Consumer #1 got new job in 0.00301 seconds
INFO:root:[Bot] New message 123456789 sent:
I am triggered

@filipre
Copy link
Owner

filipre commented Mar 1, 2022

Took me a while to find out i have to use json-rpc to get this working at all.

I will improve the on-boarding eventually. This is indeed an important detail to mention haha

@boredomwontgetus
Copy link
Author

boredomwontgetus commented Mar 4, 2022

Hi!

With increased logging and version 0.56 i can see messages incoming on stdout. No message is ever sent in response to command_1 tho.

With version 0.53 however i dont see any message incoming at all.

I only tested if i see messages incoming with wscat.

@filipre
Copy link
Owner

filipre commented Mar 7, 2022

This is very odd. I checked signal-cli-rest-api and found bbernhard/signal-cli-rest-api#224 which solved my issue in 0.57 so let's use this version from now on so we are on the same page. I also added more information on how to link and start the bot but you went through those steps already. It would be good if you check it nevertheless.

I couldn't reproduce your issues since 0.56 wasn't working at all for me and 0.53 worked without problems. Could you check the following things and post the logs?

  • Did you link your account or register a new account?
  • Confirm that you run the new version and you are using the json-rpc mode here: http://127.0.0.1:8080/v1/about
  • Confirm you can receive messages using wscat (web socket)
  • Confirm you can send messages using curl (http), e.g.
curl -X POST -H "Content-Type: application/json" 'http://localhost:8080/v2/send' \
     -d '{"message": "Test via Signal API!", "number": "+4412345", "recipients": [ "+44987654" ]}' 

If both receiving and sending works, it means that there must be an issue with receiving or sending on the bot's side.

  • What do you see in the API's stdout and the bot's stdout when you send ping, friday or command_1?
  • Does the producer pick up the message? Do consumers work on the message? If so, the issue must be the send command. Do you see the send command in the server's logs?

@boredomwontgetus
Copy link
Author

OK! I am on 0.57 now:

curl -X GET "http://kub01:8091/v1/about" -H "accept: application/json"                                                                                                                   2022-03-08 10:40:53 tom pts/1
{"versions":["v1","v2"],"build":2,"mode":"json-rpc","version":"0.57"}

I couldn't reproduce your issues since 0.56 wasn't working at all for me and 0.53 worked without problems. Could you check the following things and post the logs?

* Did you link your account or register a new account?

linked.
But this sparks an idea. Maybe its this specific group. As i do have another system running a process to pick up messages from this group. i might have to test some things here.

* Confirm that you run the new version and you are using the `json-rpc` mode here: http://127.0.0.1:8080/v1/about

Please see above.

* Confirm you can receive messages using `wscat` (web socket)

Yes. I even receive them with your example code:

SIGNAL_SERVICE=kub01.net:8091 PHONE_NUMBER="+1234567" GROUP_ID="group.alksdfjasdlkfjasf=" GROUP_SECRET="laködsfalösdkjf=" python3 bot.py
WARNING:root:[Bot] Could not initialize Redis. In-memory storage will be used. Restarting will delete the storage!                                                                                                                                     
INFO:apscheduler.scheduler:Scheduler started
INFO:root:[Bot] Producer #1 started
INFO:root:[Bot] Consumer #1 started
INFO:root:[Bot] Consumer #2 started
INFO:root:[Bot] Consumer #3 started
INFO:root:[Raw Message] {"envelope":{"source":"+12345678","sourceNumber":"+12345678","sourceUuid":"1aklds-6de1-469c-a57f-a8aafd4ae9d8","sourceName":"Bla","sourceDevice":2,"timestamp":1646732622107,"typingMessage":{"action":"STARTED","timestamp":1646732622107,"groupId":"laködsfalösdkjf="}},"account":"+1234567","subscription":0}                                                                                                                                                                                      
INFO:root:[Raw Message] {"envelope":{"source":"+12345678","sourceNumber":"+12345678","sourceUuid":"1aklds-6de1-469c-a57f-a8aafd4ae9d8","sourceName":"Bla","sourceDevice":2,"timestamp":1646732622723,"typingMessage":{"action":"STARTED","timestamp":1646732622723,"groupId":"laködsfalösdkjf="}},"account":"+1234567","subscription":0}
INFO:root:[Raw Message] {"envelope":{"source":"+12345678","sourceNumber":"+12345678","sourceUuid":"1aklds-6de1-469c-a57f-a8aafd4ae9d8","sourceName":"Bla","sourceDevice":2,"timestamp":1646732622692,"dataMessage":{"timestamp":1646732622692,"message":"ping","expiresInSeconds":0,"viewOnce":false,"groupInfo":{"groupId":"laködsfalösdkjf=","type":"DELIVER"}}},"account":"+1234567","subscription":0}
INFO:root:[Raw Message] {"envelope":{"source":"+12345678","sourceNumber":"+12345678","sourceUuid":"1aklds-6de1-469c-a57f-a8aafd4ae9d8","sourceName":"Bla","sourceDevice":2,"timestamp":1646732625724,"typingMessage":{"action":"STOPPED","timestamp":1646732625724,"groupId":"laködsfalösdkjf="}},"account":"+1234567","subscription":0}

* Confirm you can send messages using `curl` (http), e.g.

100% confirmed. Works since day 1. Tested again right now. Works.

If both receiving and sending works, it means that there must be an issue with receiving or sending on the bot's side.

* What do you see in the API's stdout and the bot's stdout when you send `ping`, `friday` or `command_1`?

Nothing ever happens. I tried all of them. All are shown on stdout with logging set to INFO. But no reply is ever sent. See output above (ping).

* Does the producer pick up the message? Do consumers work on the message? If so, the issue must be the send command. Do you see the send command in the server's logs?

No. There is no send logged to the server unless i send a message via curl.

@filipre
Copy link
Owner

filipre commented Mar 8, 2022

I found the issue. GROUP_ID and GROUP_SECRET are swapped. GROUP_SECRET is supposed to look like group.asdfasdfasd. I will document this better in a bit. Sorry for the confusion.

Here is more context:

As i do have another system running a process to pick up messages from this group.

Interesting. Could be related but it looks like the bot is picking up the raw messages, see below. I remember having problems running two API servers/signal-cli processes at the same time though.

INFO:root:[Raw Message] {"envelope":{"source":"+12345678","sourceNumber":"+12345678","sourceUuid":"1aklds-6de1-469c-a57f-a8aafd4ae9d8","sourceName":"Bla","sourceDevice":2,"timestamp":1646732622692,"dataMessage":{"timestamp":1646732622692,"message":"ping","expiresInSeconds":0,"viewOnce":false,"groupInfo":{"groupId":"laködsfalösdkjf=","type":"DELIVER"}}},"account":"+1234567","subscription":0}

This means, the bot is receiving messages because we see the raw message in the logs. However, we don't see any consumer picking up the message. That implies, there is an issue in "listening" to messages for that group.

@filipre
Copy link
Owner

filipre commented Mar 8, 2022

Check out the new Readme and let me know if you have feedback.

@boredomwontgetus
Copy link
Author

hi!

thank you. i changed GROUP_SECRETfor GROUP_ID. This does unfortunately not change anything.
I also tested with the other signal-cli processes stopped. Does not show any change either.

I looked at the new README.
It is sill a bit confusing IMHO. I mean, i get it in the meantime but i can imagine other ppl will still struggle there.

This part:

- `GROUP_ID`: Group that the bot should listen to. Currently, only groups are supported.
- `GROUP_SECRET`: Group's `internal_id`. You can get it by calling `http://127.0.0.1:8080/v1/groups/{number}/{groupid}`, see [API documentation](https://bbernhard.github.io/signal-cli-rest-api/). It should be prefixed like this: `group.*******************=`

i think the clearest part to get the info we need is by executing something like:

curl -X GET 'http://signal-cli-api.examle.com/v1/groups/+4912312321323' | python -m json.tool

and then just describing that the key id maps to GROUP_SECRET and internal_id maps to GROUP_ID.

@filipre
Copy link
Owner

filipre commented Mar 10, 2022

and then just describing that the key id maps to GROUP_SECRET and internal_id maps to GROUP_ID.

No, its the other way round! GROUP_ID must map to id and GROUP_SECRET must map to internal_id, which should be already prefixed with group.
Edit: nope what I wrote is not true, my mistake 🤫

I am still convinced that this is the issue in your case but I am a bit out of ideas. Are you sure that your ids end with a = and are strings? Maybe some special character is messing up the env variable. Do you use VS Code? You could use this config to start the debugger and to set a break point in here

{
    "name": "Examplebot 127.0.0.1",
    "type": "python",
    "request": "launch",
    "program": "${workspaceFolder}/example/bot.py",
    "console": "integratedTerminal",
    "env": {
        "PYTHONPATH": "/path/to/the/signalbot/example",
        "SIGNAL_SERVICE": "127.0.0.1:8080",
        "PHONE_NUMBER": "+49123456789",
        "GROUP_ID": "asdfadfadsfasdfasdfasdfasdfasdf=",
        "GROUP_SECRET": "group.qwerqwerqwerqwerqewrqwerqerqwerqwerqerqerqwerqwer="
    }
},

self.groups should look like this in your debugger

self.groups = {
     "asdfadfadsfasdfasdfasdfasdfasdf=": "group.qwerqwerqwerqwerqewrqwerqerqwerqwerqerqerqwerqwer="
}

We need the id to listen for group messages so we don't enable the Bot in every group. The internal_id on the other hand is used for sending messages. That's the reason why we need both.

If you don't run into continue, it means something is off with the task queue here

It is sill a bit confusing IMHO. I mean, i get it in the meantime but i can imagine other ppl will still struggle there.

Okay, I will think about making it clearer.

@boredomwontgetus
Copy link
Author

No, its the other way round! GROUP_ID must map to id and GROUP_SECRET must map to internal_id, which should be already prefixed with group.

ok.
looks like i am still super confused. lets look at this output:

10063 example:master % curl -X GET 'http://signal-cli.sweethome.net/v1/groups/+4123214124' | python -m json.tool
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current                                   
                                 Dload  Upload   Total   Spent    Left  Speed
100   564  100   564    0     0   115k      0 --:--:-- --:--:-- --:--:--  137k
[
    {
        "name": "testgroup",
        "id": "group.adsfasdfadsfadsfsadf=",
        "internal_id": "dOjyESVDTUMzJVOOMk5LepU3c=",
        "members": [
            "+432132123",
            "+4312312373"
        ],
        "blocked": true,
        "pending_invites": [],
        "pending_requests": [],
        "invite_link": ""
    },
    {
        "name": "bla",
        "id": "group.adsfadsfadsfwerw213VczNHT2xEWT0=",
        "internal_id": "nUy9VdR0jIiqM8M9Ogu5pWKxhEr1yXU5hVFUs3GOlDY=",
        "members": [
            "+4361232142143",
            "+4312312412342"
        ],
        "blocked": false,
        "pending_invites": [],
        "pending_requests": [],
        "invite_link": ""
    }
]

i understood from your post earlier:

id => GROUP_SECRET
internal_id => GROUP_ID

I found the issue. GROUP_ID and GROUP_SECRET are swapped. GROUP_SECRET is supposed to look like group.asdfasdfasd. I will document this better in a bit. Sorry for the confusion.

@filipre
Copy link
Owner

filipre commented Mar 10, 2022

🤦🏻‍♂️ you are right. I will change the names to GROUP_ID and GROUP_INTERNAL_ID to make it clearer and I will also refactor the whole .listen() method and the Readme. It still doesn't explain why swapping the variables didn't work for you. As I mentioned

SIGNAL_SERVICE=bla.foo.net:8091 PHONE_NUMBER="+40123456789" GROUP_ID="group.blV5OVZkUjBqSWlxT02304234kladjfklaejrT0=" GROUP_SECRET="dasfasdfawefadfaseGOlDY=" python3 bot.py

must be

SIGNAL_SERVICE=bla.foo.net:8091 PHONE_NUMBER="+40123456789" GROUP_SECRET="group.blV5OVZkUjBqSWlxT02304234kladjfklaejrT0=" GROUP_ID="dasfasdfawefadfaseGOlDY=" python3 bot.py

but this is what you tried out.

In bot.py you can replace signalbot with src.signalbot and then set a break point as described above. I don't have any other idea how to solve the issue. It would be very interesting to see where the code fails in your case.

@filipre
Copy link
Owner

filipre commented Mar 12, 2022

I created #8 to make .listen() work for user chats (phone numbers) and use the swapped order as a "backup". I want to test it a bit more, but will release it soon. I dont expect it but maybe it will fix your issue. I also changed the names to GROUP_ID and GROUP_INTERNAL_ID

@boredomwontgetus
Copy link
Author

hi! thank you very much for your effort! i think it has to do with my setup. but i dont have the time to look into this in more detail at the moment. i will look into it again whenever i get there.
you can close this issue, if you want to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants