That is exactly what I did in the first place.
Sorry to reply so late. But it has been bugging me that you can be both wrong and right at the same time. Yes I accept every host name (in my setup) which as you say, it is the client that sends this information. So therefore it cannot be thrusted. Therefore it is has no use in doing any security checks. If tt-rss does use this as a “security” measure it should be reviewed.
I am a happy user of tt-rss since google killed off their site. I personally dislike php which is a huge reason for not contributing with MR. Second reason is the tone in this forum. I do have 20+ year in software development. And also quite well understanding of HTTP
The reason for me to accept multiple host name is to have (testing of) fail-over.
fox
17
before making vague accusations maybe at least read the code or something
especially because the only (mild) security issue here is something that literally you tried to introduce in this very thread - for example, with Host being manipulated either in transit or locally this could cause your browser to be redirected somewhere you wouldn’t expect
nobody cares
You want to use multiple host names with a single TT-RSS install and want to use some crazy workaround to do it. I provided a safe way, which for the third time is to simply redirect other domains to the single domain actually hosting TT-RSS.
But somehow I’m wrong or TT-RSS is not secure?
That… isn’t how failover works.
Which sorta makes me wonder if that “20+ years” is “the same year” 20+ times over.
Anyway, </ot>
fox
20
that feel when nobody appreciates your 20 year career writing stuff using microsoft access
I had the same issue (same host, two interfaces: one public over reverse proxy and one over tinc vpn, tt-rss and proxy on different machines).
I solved the problem by disabling the check and setting the SELF_URL_PATH to a single dot. Whatever check needs to be done on hostname value is handled by my webserver, it doesn’t respond without a proper host header for which it’s been configured.
I stand corrected, doing this breaks af_imageproxy when using the android app.
This is a bit of an old topic, but it is easily found, so I would still like to ask for help here.
I have tt-rss running behind from a webserver, on address 10.0.0.1 port 8081, which itself is behind a load balancer with the public address like example2.com.
define(SELF_URL_PATH, $_SERVER['HTTP_HOST'] == '10.0.0.1:8081' ? 'http://10.0.0.1:8081/tt-rss/' : 'https://example2.com/tt-rss/' );
But this does not work, tt-rss is complaining about
Please set SELF_URL_PATH to the correct value detected for your server: http://example2.com/tt-rss/
So, the difference is in the “s” letter.
What do I need to set in my URL rewriter in order for tt-rss to correctly do all requests to the port 443?
If I just
define(‘_SKIP_SELF_URL_PATH_CHECKS’, true);
everything breaks apart, that is, although the main page loads, all ajax requests seem to go to http://example2.com/tt-rss/, which does not exist.
For clarity, the cgi webserver is OpenBSD’s httpd, and the load balancer is relayd.
fox
24
behind a load balancer with the public address like example2.com.
all ajax requests seem to go to http://example2.com/tt-rss/, which does not exist.
what. a load balancer that doesn’t exist?
i need to start probating people who can’t figure out x-forwarded-proto.
SELF_URL_PATH should be set to the URL user is seeing in the browser. you’re overcomplicating things, i think, or your frontend is misconfigured. your internal IP addresses shouldn’t ever be in there.
also, under no circumstances you should use _SKIP_SELF_URL_PATH_CHECKS.
what. a load balancer that doesn’t exist?
The load balancer exists, it’s just not listening on HTTP 80.
x-forwarded-proto
How would I have figured it out? I had never heard about it before.
Things seem to work with the following setup:
match request header set "X-Forwarded-For" value "$REMOTE_ADDR"
match request header set "X-Forwarded-By" value "$SERVER_ADDR:$SERVER_PORT"
match request header set "X-Forwarded-Ssl" value "On"
match request header set "X-Forwarded-Proto" value "https"
match request header set "Host" value "example2.com"
match request header set "X-Real-IP" value "$SERVER_ADDR"
match response header set "X-Frame-Options" value "SAMEORIGIN"
your internal IP addresses shouldn’t ever be in there.
The internal IP is critical because I need the hosts from 10.0.0.x to access 10.0.0.1:8081 directly, instead of going through the load balancer. In particular, they should not be dependent on the TLS setup, whereas things accessible through example2.com are only allowed to access through TLS.
I would like to point out that this is not how you should be doing this (accessing the same resource by a different address internally versus externally).
What is often done is that a domain name is used that, on the internal network, resolves to a specific address but externally resolves to another. Another common solution is to simply limit access to only the internal network, then have clients connect through a VPN. Such connections can often be configured to work “on demand” so the user has a fairly seamless experience.
Also:
A load balancer that always points to a single instance of TT-RSS? The application isn’t even designed to scale to the point where a load balancer would even need to be a thing.
I’m trying to imagine a sequence of events that allows a person to require a load balancer but never come across forwarding information.
e: And while perhaps not specific to this thread. Nginx in Debian basically comes with an include to handle most of this:
# cat /etc/nginx/proxy_params
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
fox
28
tbh i wouldn’t really expect anything more from someone who unironically uses openbsd - a “research”
(i.e. unfit for production use) operating system with all the performance of an unoptimized 50 year old unix combined with the most embarrassing security vulnerabilities of the whole bsd family.
this stuff is how you spot people who have no idea what they are doing before they admit to their inability to learn things on their own.
also,
remember, he’s using openbsd’s httpd with cgi. this shit is so unimaginably slow he might actually need a bunch of load balancers, lol.
What is often done is that a domain name is used that, on the internal network, resolves to a specific address but externally resolves to another.
That’s hard to enforce for machines that are on both networks at the same time.
Another common solution is to simply limit access to only the internal network, then have clients connect through a VPN.
The “internal network” IS a VPN. And in addition to being on a VPN, each machine is also connected to the “outside world” via its own internet connection. It’s simple actually, I set up a “go home” VPN on each of my workplaces, so that I can set up the VPN the way I like, do all the development on any of the machines without caring about encryption from the first day, because everything is already encrypted by the VPN. Otherwise, each machine is a legitimate member of it’s won enterprise network, and has a DNS supplied by the ISP.
A load balancer that always points to a single instance of TT-RSS?
A load balancer is pointing to different services, dispatching on the URL. /tt-rss points to just a single instance of TT-RSS, but there are many more things behind relayd, which is responsible for TLS for each of those services.
I’m trying to imagine a sequence of events that allows a person to require a load balancer but never come across forwarding information.
It is simple, I first came across load balancers two days ago.
I have a related use case that I’m not sure how to handle:
I’m looking at installing the Docker container flavor of tt-rss on my home LAN and then forwarding a single port to it from the WAN. I have two dynamic DNS services pointing to my WAN IP. Is it possible to make the same tt-rss instance work via either domain, plus ideally the LAN hostname, or do I really need to resign myself to using only one domain for all use cases?
fox
31
you’ll need to write php code in config.php to call putenv("TTRSS_SELF_URL_PATH=...") based on contents of $_SERVER or $_REQUEST or whatever. a few simple if blocks would do the trick, i think.
you could even set self url path to HTTP host directly, however i would suggest having some kind of whitelist for predictability.
Isn’t config.php autogenerated in the container flavor of tt-rss, though, or is that just on deploy?
fox
33
not anymore, you need to create it manually.
In that case, the readme is out of date, as it says not to do this:
Main configuration file (config.php) is rewritten on startup, don't edit it manually. Use environment variables or config.d snippets to customize it.
