Tiny Tiny RSS: Community

Docker image behind nginx proxy

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.

  1. stock .env file is now .env-dist, don’t forget to copy it to do any modifications
  2. you should be able to set correct value of SELF_URL_PATH in .env and it should apply after container restart

you 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.

:man_facepalming:

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!

Sorry, I don’t usually behave that way, but it seems the style here.

And mods continue to engage :man_facepalming:

I guess you rather want to be ignored? That doesn’t seem very polite…

Your idea is stupid. You might be stupid or not, no judgement is given there.

I have plenty of stupid ideas. I am generally very happy when someone points this out. It is called the market place of ideas. If an idea is so weak it cannot survive there, it is a bad idea. Do not use it.

Security by obscurity is no security at all. It is wasted effort. Please do not do it.