search

immanuelfodor / rocketchat-push-gateway

A push gateway for RocketChat to send notifications through Gotify
Do What The F*ck You Want To Public License
42 stars 7 forks source link

A second chance to the push gateway #5

Closed githubdeb closed 1 year ago

immanuelfodor commented 2 years ago

Hi @githubdeb,

However, I would need a way to read from RC the user who send and the one who receive ids and very-long-token and the payload. I saw all this information in the RC logs, but I don't know where I can read it with code.

In this case, you'd need to modify the codebase of RC or develop a custom "plugin" to read it since this information only exists in RC internally, so you'd need to hook into this internal event. That is why they make it available as a "webhook" with the possibility to receive the event as a HTTP POST message through a push gateway. I think it's a lot easier to use the gateway than to modify and constantly rebase RC's codebase.

In this situation I don't think I need apprise.

Theoretically, it's correct, you could just curl the Gotify server but see the previous explanation. With this gateway, apprise makes the curling a lot easier through their Gotify notification channel which hides the implementation details and we just need to pass a couple of parameters to make the call.

I'm trying to make it work without docker.

Of course, it's possible, Docker just makes the packaging and setting up the environment easier and reproducible. Should you have Python installed in a VM or LXC container or some bare metal machine, install the requirements with pip, start the gateway as a service at boot, and you're good to go.

Clearly it does not find something.

Yes. To debug this, you need to be aware on which hosts the my.domain.com is resolvable to where through DNS and what is considered as localhost from which perspective (client side, server side). You need to be able to curl the gateway from the server running RC (if it's a container, then from within the container), and you need to be able to curl Gotify from the server running the gateway. Furthermore, all the payloads and configs need to be the same and correct that would each service expect, so for example, what you added to the push gateway's apprise config, you need to use those parameters when curling from there to be sure that everything works. I think your problem resolves somewhere here. Try to visualize on a network diagram where your services are installed, where working or not working communication happens, etc, it might help, just as rubber duck debugging.

githubdeb commented 2 years ago

Ok.

  1. I can curl the gateway from the server running RC. In fact both are on the same machine. It works when I curl to http://localhost:5000 from command prompt.
  2. It also works when I curl from command prompt to Gotify server. My general schema looks like this RC Server ------> push settings (http://localhost:5000) ------->apprise file -------> Gotify server.

1 and 2 means everything from push settings(http://localhost:5000) -----> apprise file ------>Gotify server works. The only part not working is the one from RC to the push gateway. I don't get push notifications to Gotify from RC. Any ideas?

immanuelfodor commented 2 years ago

And no Docker is involved anywhere in the process? All the servers (RC, push gateway, Gotify) run with native install on the same machine exposed by their default ports?

githubdeb commented 2 years ago

Correct. No Docker is involved anywhere. All the servers (RC, push gateway, Gotify) run with native install on the same machine using their default ports.

immanuelfodor commented 2 years ago

Well, that is most interesting, localhost should mean the same machine in all contexts.

One thing I can think of is that RC is in fact not sending any push notifications out. There are cases when RC thinks that the recipient has already seen the message, so it doesn't send a push out. Try being in a channel with 2 users, and avoid using the 2nd user's account on the web in another browser (tab) or on mobile (it should have a mobile device login, of course), then send a message in that channel with the 1st user. In this case, a push should be definitely triggered for the 2nd user as they can't see the message on any of their devices (web or mobile).

One other thing to try is to use an online request bin to examine the push contents. A problem may be that the link should contain RC's expected path but this one for example can handle an arbitrary path behind the UUID in the URL: https://webhook.site/ so add the URL with UUID as push gateway in RC's settings (e.g. https://webhook.site/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx/ , and see what happens with the first method, is there any push at all, and if yes, what the content is.

Third idea is to change localhost to its IP equivalent 127.0.0.1, so http://127.0.0.1:5000/ . Maybe npm resolves it to something else, I don't know.

immanuelfodor commented 1 year ago

I close this issue for now as I don't see any problem with the gateway itself, this must be an issue with the hosting environment. We can continue the debug on the closed issue anyways.