sasl-xoauth2-tool option for reverse proxy HTTP host/port and local port
SunMar opened this issue · 3 comments
Hi,
Thank you for the amazing plugin! Managed to get it working nicely without much effort.
One thing I ran into is that the sasl-xoauth2-tool
always uses 127.0.0.1 as the redirect host and the port is randomized. Would it be possible to make the below things configurable?
- IP to bind the HTTP server to
- Port to have the HTTP server listen on
- HTTP host for the callback URL
- HTTP port for the callback URL
If these 4 things are configurable via a simple environment variable (or by passing a parameter to the script), it greatly simplifies putting this in a Docker container. Point 1 is to be able to listen on 0.0.0.0 in a Docker container, point 2 is to allow for a fixed port to be able to use docker port mappings, and points 3 and 4 are to be able to set the proper host/port of either a reverse proxy or the machine the container is running on.
Only an idea though. I managed to make an easy workaround by creating a Python script that starts sasl-xoauth2-tool
, asks for the URL you were redirected back to, and then calls that URL from the script.
Related code:
sasl-xoauth2/scripts/sasl-xoauth2-tool.in
Lines 50 to 59 in 41b27db
I think this is all doable, but I first want to make sure I understand the use case. Why not just run sasl-xoauth2-tool
on whatever host doesn't require a reverse proxy and then transfer the resulting token file (with scp
or whatever) to the container?
Thanks for the reply!
It's ease of use. I have created a Docker container that runs Postfix and allows relaying of email using sasl-xoauth2
, this way I can send notifications via Gmail from applications that natively only support plain SMTP. I run almost everything as a Docker container on a remote server.
The Docker container needs to be setup regardless to have the SMTP available. Adding a few parameters to an already scripted container is easier than having to setup and configure sasl-xoauth2-tool
on another machine and then having to transfer the file. If I need to recreate the token in a year from now, the Docker container is still going to be there but my machine may have been reinstalled or replaced. That can also make it a hassle to generate a new token. That's why I prefer to do it inside the Docker container where sasl-xoauth2
will also be running. For me personally, it's easier and safer.
Still, I'm also perfectly happy with my workaround since tokens don't need to be recreated often, if ever at all.
I have the same use case. I have a Windows workstation, but all my code runs in Docker containers.
I ended up hacking sasl-xoauth2-tool
to use a predetermined port (instead of using 0), which I had Docker forward to the Docker container running sasl-xoauth2-tool
. That did exactly what I needed.