Tiny Tiny RSS: Community

[SOLVED] SELF_URL_PATH for host with two hostnames?

Hi,

my server is accessible via two different hostnames. I currently use

define('_SKIP_SELF_URL_PATH_CHECKS', true);

to suppress the error message about incorrect SELF_URL_PATH for user coming in via the hostname that is not defined in SELF_URL_PATH, but I was wondering if there is a way to configure SELF_URL_PATH that such a not recommended workaround is not needed anymore. Is there a way?

i’m afraid not. i think this goes from one of server provided variables so you should be able to override that through httpd.

Okay, thanks @fox. If somebody here has done that with nginx and knows how to set the correct variable, it would be nice if they could share that information.

it’s “Host” just google how to override it, its like 1 line in nginx

My google results pointed to setting

fastcgi_param SERVER_NAME $http_host;

which I tried but that didn’t work. Do I need to set a fixed value here - the one used in SELF_URL_PATH - instead of $http_host here?

This works for me in config.php:

   define('SELF_URL_PATH', 'https://'. $_SERVER['HTTP_HOST'] . '/tt-rss/');

I am definitely not a php expert so there could be better ways.

Thanks @schafdog, that did it! I was always searching for nginx config settings and it didn’t occur to me to set it in the config.php.

tbh you might just as well disable the check then since its effectively doing nothing

From the comments in the config.php I read that SELF_URL_PATH needs to be set to the correct URL to enable certain features. The setting proposed by @schafdog ensures that in my setup: No matter which hostname is used to access tt-rss, the setting in config.php is dynamically adjusted to the name the user used.
If I would disable the check, users could access the site from both hostnames, but the one that differs from the hostname used in the SELF_URL_PATH setting could break the settings for which it is apparently needed (PUSH, bookmarklets and browser integration according to the config.php comment).

the whole point of having this as a defined constant is this value being accessible from context where http server variables are not available, for example a command line script on your server

adding $_SERVER or whatever in there is completely pointless and stupid. otherwise i’d just use it instead and this constant and related checks wouldn’t exist.

You’re setup now accepts any host name. The host name is provided by the client, which means you’re blindly using client-provided information without any checks in place. This could be used by malicious actors at some point. It’s an unlikely possibility, but it’s a possibility nonetheless. That’s without the other considerations for how well TT-RSS is going to operate, as fox mentioned.

The correct way of doing this is to have a single host name for your TT-RSS install and use redirects on the other host names so they all go to a single location.

If you’re set on doing this crazy setup (which is seems you are :man_shrugging:) then do something like this:

define(SELF_URL_PATH, $_SERVER['HTTP_HOST'] == 'example1.com' ? 'example1.com/tt-rss/' : 'example2.com/tt-rss/' );

This basically creates an exception for one, single host name; otherwise it falls back to the default. In either case you’re not trusting client-provided information but setting your own.

$_SERVER[‘HTTP_HOST’] is set by nginx and nginx sets it only to the values it is configured for via the servername settings in the nginx site config.

I was under the impression that HTTP_HOST would be populated with the Host header the client provides. The documentation seems to support this:

$http_ name

arbitrary request header field; the last part of a variable name is the field name converted to lower case with dashes replaced by underscores

Regardless though you should configure Nginx to support multiple host names within the viritual host:

server {
    server_name example1.com example2.com;

    ...
}

In your post above you were overriding $_SERVER['SERVER_NAME'] in Nginx’s conf files but still checking $_SERVER['HTTP_HOST'] when inside PHP.

Nonetheless, if you need to pass this to the PHP interpreter, then create a variable like X-CLIENT-HOST (i.e. something non-standard so as not to interfere with anything else) then do the check in config.php as I detailed above to only allow approved host names.

Or

Just set the frickin’ constant and walk away. The whole point of that constant is to handle edge cases gracefully. Why create all this work unnecessarily because you don’t want to define a single value as true and skip the checks?

Again

yeah op this what you should’ve have done in the first place

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.

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?

:face_with_raised_eyebrow:

That… isn’t how failover works.

Which sorta makes me wonder if that “20+ years” is “the same year” 20+ times over.

Anyway, </ot>

that feel when nobody appreciates your 20 year career writing stuff using microsoft access