AGWA / sms-over-xmpp

XMPP Component (XEP-0114) to send and receive SMS
Other
77 stars 10 forks source link

HTTP... I'm completely confused here #40

Closed k0d3g3ar closed 3 years ago

k0d3g3ar commented 3 years ago

So I have a Prosody server up and running - can connect to it just fine with Jabber clients, etc. I have built the sms-over-xmpp app and it is running. Setup a config file for it, and I've setup Twilio to webhook to a URL that should reach the server. Checked all the firewall settings, etc. to make sure nothing is blocking.

What I can't seem to work out for the life of me is how the architecture of the HTTP server works here. Took a quick look at the code (I'm not a Go developer) but I see that it has its own HTTP server. So I've put this on port 9677.

I run the sms-over-xmpp app with the config file, and it looks ok to me. No complaints. The Prosody logs show that it loaded the component that was referenced in its configuration, etc.

I expect that since I'm running the sms-over-xmpp as its own app, and set to serve on port 9677, that this IS the web server, right? I don't need to be running Apache or Ngnix or something like that to front-end this, right? I mean if it is on the same NIC interface as Prosody, that shouldn't matter since it is serving only on its own unique port.

Assuming that I'm right so far, what is never stated in the documentation is whether this app has to be started on its own each time the server is booted? I'm assuming it does, since it is the web server, right?

So having configured hundreds of Apache servers in my time, what I don't understand here is what is the Webroot for the sms-over-xmpp web server? The HTTP URL that is required for the Twilio webhook (and what I've seen as "/path/to/sms-over-xmpp" in the docs) assumes that I have to point to this web server, but why would I need to do that if it is the web server? I have it running and if I curl to the port 9677, I get a blocked connection. I'm sure I am supposed to put some additional values here in the URI for the request, but what?

There is probably something fundamentally wrong with my assumptions here. Can someone please tell me what I'm misunderstanding, or if I am on the right track, what is the webroot for the sms-over-xmpp component, or at least an example of an actual config file so I can copy from it?

Thanks Myles

AGWA commented 3 years ago

Hi Myles - you're on the right track here.

I expect that since I'm running the sms-over-xmpp as its own app, and set to serve on port 9677, that this IS the web server, right? I don't need to be running Apache or Ngnix or something like that to front-end this, right? I mean if it is on the same NIC interface as Prosody, that shouldn't matter since it is serving only on its own unique port.

Correct on all counts. That said, you might want to put it behind an Apache or nginx reverse proxy so you can use HTTPS, which sms-over-xmpp does not presently support.

Assuming that I'm right so far, what is never stated in the documentation is whether this app has to be started on its own each time the server is booted? I'm assuming it does, since it is the web server, right?

Correct.

So having configured hundreds of Apache servers in my time, what I don't understand here is what is the Webroot for the sms-over-xmpp web server?

The webroot, if I'm understanding your question correctly, is just /. In other words, the URL of the Twilio webhook would be http://USERNAME:PASSWORD@HOSTNAME:9677/, where USERNAME and PASSWORD match your config and HOSTNAME is the publicly-accessible hostname or IP address of your server. You would only need a path if you have placed sms-over-xmpp behind a reverse proxy and are reverse-proxying a path rather than the entire virtual host.

I have it running and if I curl to the port 9677, I get a blocked connection.

That's odd. In the [http] section of your config, make sure you set the host option to 0.0.0.0. By default, it listens on localhost only, which might explain why you can't curl it.

Here's a working example of the [http] section:

[http]
host = "0.0.0.0"
port = 9677
username = "twilio"
password = "supersecretpassword"

Let's say your server's public IP address is 192.0.2.10. Then your Twilio webhook URL would be http://twilio:supersecretpassword@192.0.2.10/. Assuming sms-over-xmpp is running and there aren't any firewalls blocking port 9677, this should work.

k0d3g3ar commented 3 years ago

Thank you. That really helps. I'm trying your revised branch at the moment. That seemed to say much the same thing in the config docs, so it is starting to make sense now.

One question.... Is there any URI that can be used with this as a test request? Just something that returns back a response so that while someone is setting up the servers, firewalls, etc. they can detect if there is something outside of the app that is blocking traffic? I think that would help reduce the support demand in that area.

AGWA commented 3 years ago

I'm glad you're trying out the revised branch! I recommend sticking with it because it will be the future of sms-over-xmpp. It's what I'm currently running in production, and it has cool features like MMS support.

You probably saw this in the docs, but with the revised branch the Twilio webhook URL does have a path. Specifically it's of the form http://twilio:HTTP_PASSWORD@HOSTNAME:PORT/PROVIDER_NAME/message. Let me know if you have any questions about that.

That's a good idea about a test URL. For now, you can just try fetching the root of the server and it will return 404 page not found if it's working.

k0d3g3ar commented 3 years ago

OK, I can also see on the console that it is doing a "Keep Alive" thing by the look of it. Trying every 60 seconds, etc. Is that a correct interpretation?

AGWA commented 3 years ago

Every 15 seconds it sends a "whitespace ping" to the XMPP server. This is what it looks like in the log:

2021/07/16 20:47:41.897927 |>  
k0d3g3ar commented 3 years ago

I got it working! This is awesome. Your new revisional branch is perfect. I would suggest making it the main branch ASAP. The instructions alone are far easier to work with, and it turned out that my issues were due to network routing problems. Once I got past that, it all worked flawlessly.

AGWA commented 3 years ago

I'm glad you got it working! I just merged the rewrite branch into master.