[SOLVED] SELF_URL_PATH for host with two hostnames?

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.

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.

:man_facepalming:

/20char

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;

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?

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?

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.

ah oops, I guess this needs to be updated.

Adding the following lines to a php file in config.d/ works for me:

<?php
# Set SELF_URL_PATH based on request                                                                                               
if (php_sapi_name() != "cli") {
   $protocol = $_SERVER['HTTP_X_FORWARDED_PROTO'];
   putenv('TTRSS_SELF_URL_PATH=' . $protocol . '://'. $_SERVER['HTTP_X_FORWARDED_HOST'] . '/tt-rss/');
}
?>

if i were you, i wouldn’t blindly trust contents of those variables and run them through some kind of whitelist instead (filter proto to http, https) etc.

Fox, I also use some code to set the URL and after this discussion wondered if you might change the base code to have an array of “allowed URLs” (full URL with protocol and host). If this exists and the inbound address is in the array, use it. If a user wants current behavior they can only have a single URL in the array.

i dunno, a comma separated list of URLs could work but it seems like a very niche feature, which is easily solved with config.php anyway.

e: a safer version of the above snippet could be added to faq