Since I spend some hours trying to get the docker image up and running behind a nginx reverse proxy with https just a simple yes no question to get started
Is there somebody out there who was successful with running the docker images behind an nginx reverse proxy on the top level url? Just https :// www yourdomain c
I changed the SELF_URL_PATH to the desired domain and the ngnix location is /.
When accessing the url I always get an “tt-rss” added to the url.
This isn’t really the place to be asking these kinds of questions because it’s not specifically TT-RSS related. You can search sites like stackexchange, etc. and they’ll have tons of examples to get you going.
Using Nginx as a proxy is pretty straightforward. If you have TT-RSS setup and working in Docker you just need add a virtualhost to your Nginx setup with something like:
location / {
proxy_pass http://0.0.0.0;
# include proxy_params;
}
proxy_pass can point to anything but usually you would use the IP (of your Docker instance). You may want to include a few more things in the location section. I know Debian ships with a set of predefined parameters that you can use with include proxy_params;. These include some common things for setting Host and Forwarded values (I commented that line for those who are not on Debian and copy/paste, so just uncomment it if you’re using a recent version of Debian).
In your TT-RSS config, you should define the SITE_URL to be the public facing name; that is, the name the reverse proxy is using, not the name or IP the Docker instance is using.
I use Linux containers versus Docker but my setup is basically the same: With TT-RSS running in its own container and a proxy running separately that forwards. If you have Docker specific questions others here can answer those, but look around on the Internet for Nginx reverse proxy, there are tons of tutorials.
e: Just to add, you’ll need to post some excerpts from your configs if you need more help. It’s difficult to figure out things like redirecting without seeing a bit more of your setup. (Please replace domain names and external IPs with generic information.)
That was a simple yes/no question and not a generic question for help to configure it. You have not answered it. I am not an expert but I already have multiple docker/non docker services behind a nginx so this is not the first exercise for me.
Are you running the docker-compose setup provided here " A primitive set of scripts to deploy tt-rss via docker-compose" on the top level of a domain behind a nginx reverse proxy?
I have doubt that it is possible. This is why I am asking.
if you’re running those docker scripts, then not out of the box. it’s supposed to work as a /tt-rss/ location. reason being it’s easier to host behind a frontend without making a separate subdomain.
ok, since now I understand that the tt-rss is required next question. It is a little bit proxy related but It seems to me that my problem is in the tt-rss area
This is my nginx proxy configuration
location /tt-rss/ {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://127.0.0.1:8280/tt-rss/;
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
break;
}
I changed my docker-compose self_url_path
SELF_URL_PATH=https://www.mydomain.de/tt-rss/
But I get this error
# Startup failed
Tiny Tiny RSS was unable to start properly. This usually means a misconfiguration or an incomplete upgrade. Please fix errors indicated by the following messages:
Please set SELF_URL_PATH to the correct value detected for your server: **https://www.mydomain.de/tt-rss/**
And yes. the proposed domain in the error is exactly the external domain I put in the browser and the string that is in docker-compose.
This is also happening when removing the auth restriction
I am sure its my fault but I really cant see it.
you have to update SELF_URL_PATH in generated config.php on the persistent volume or rebuild the container from scratch (removing all used volumes).
e: alternatively, wait a bit and i’ll change startup scripts so SELF_URL_PATH is rewritten to the value specified in docker-compose.yml on restart.
you’re supposed to know basic things about docker, like persistent volumes.
container are rebuilded every time
docker-compose down && docker-compose rm && docker-compose up --build
``alright, try updating to latest git version of docker scripts.
.env file is now .env-dist, don’t forget to copy it to do any modifications.env and it should apply after container restartyou are probably right. After operating 2 webshop, a mailman server and matomo in docker behind a nginx I probably have reached the limit of my capabilities in running tt-rss. It is certainly my fault and I will not continue this approach.
Nobody knows, what your knowledge is. If you running, what you are saying, it should be easy to have a look into the source code? Here you see, that the container will always redirect to the sub-url, as it is also located in there, if you would have a look into the docker container.
As is clearly stated in the README “Not fully tested yet, don’t use in production unless you know what you’re doing. Some features may be unimplemented or broken,”.
Your other used containers most likely are somewhat idiot proof and prepared for people which have not much knowledge about what is happening if they are running those containers… (like you seem to be, sorry)
Another n00b with the same issue here. I like to put those self-hosted apps behind random URLs. The hard-coded redirect to tt-rss in index.php prevents that.
The SELF_URL_PATH check also seems to not take into account the proxied URL, so I needed to disable it by modifying app/startup.sh. Maybe this use case (reverse proxying at custom URL location) could be made more user friendly?
Why do you want to do that?
Defence in depth. Someone scanning for /tt-rss when there is a pre-auth exploit available doesn’t find it in the first place if it is at /random-url while it is still easily accessible.
That said, I put basic http authentication in front now – same idea but less convenient (e.g. if I want to share a link) and idk if it’ll work with the apps.
Okay.
Security is done in layers. Security by obscurity can be one of those layers, but it’s not real security. You’re better off following best practices such as keeping software up-to-date, least privileges, using containers, etc.
If you really want to go this route, you can keep TT-RSS the way it is and make these changes on your proxy. So that the proxy remaps what is necessary. I think Nginx has some options for this. You probably won’t get much support here if you go this route though because it’s an Nginx thing and not a TT-RSS thing.
I’ll say it again, security by obscurity is not real security. If you are genuinely concerned about being compromised, put some additional barriers in place such as fail2ban (to block multiple failed login attempts), IP limits at the firewall, or additional authentication on the front end such as HTTP authentication (with either username/password or certificates).
e: TT-RSS supports HTTP auth with password or certificates so it’s a great way to block the entire application, while still being user-friendly (i.e. only logging in once).
As said, I’m now using basic http authentication, so not “security by obscurity”.
Using a random URL has about the same result as basic http auth sometimes, while being more convenient. TT-RSS might not be the best app for that because it leaks the referrer to all the links one clicks, but that’s still only a tiny problem.
The difference between “security by obscurity” and hiding the service at a sufficiently random location is that “security by obscurity” can be overcome in a (small) amount of time by an attacker (e.g. if I put ssh on a non-random port an attacker just needs to do a full port scan). Good luck finding the URL if it has 128 bit of entropy.
I fixed that for you.
I fixed your post. Thanks!
this is one of the most stupid ideas i’ve seen being posted here.
e: after reading your other posts itt, can you just fuck off back to reddit or wherever you came from? thanks. go be an idiot somewhere else.
You are stupid to engage users that way. If I don’t like something in my forums I either ignore it or am polite.
Anyway turns out FreshRSS can be setup that way, so I have switched to that (like OP).
Now, now, that is no way to behave.
Bye!