TTRSS served on custom port (not about feeds)

Tiny Tiny RSS Support
1
  • [ ] I’m using stock docker compose setup, unmodified.
  • [x] I’m using docker compose setup, with modifications (modified .yml files, third party plugins/themes, etc.) - if so, describe your modifications in your post. Before reporting, see if your issue can be reproduced on the unmodified setup.
  • [ ] I’m not using docker on my primary instance, but my issue can be reproduced on the aforementioned docker setup and/or official demo.

This post is not about feeds served on non-standard ports, I swear :slight_smile:

I have setup TTRSS_SELF_URL_PATH: "https://ttrss.mydomain:8000/tt-rss/".
All works well, except after logging in when TT-RSS redirects me to https://ttrss.mydomain/tt-rss/.
After logging in, I need to add the port to the URL and it works. I guess this is a typo somewhere in the source code?
Note that the mobile app on Tiny Tiny RSS - F-Droid repository works without issues despite this.

Here are the X headers I pass to TT-RSS from a LAN IP

  • X-Forwarded-For: 172.16.10.6
  • X-Forwarded-Host: ttrss.mydomain:8000
  • X-Forwarded-Method: GET
  • X-Forwarded-Port: 8000
  • X-Forwarded-Proto: https
  • X-Forwarded-Ssl: on
  • X-Forwarded-Uri: /tt-rss/
  • X-Real-Ip: 172.16.10.6
  • X-Remote-Addr: 172.16.10.6
  • X-Ssl: on

Technical information:

  • Tiny Tiny RSS version (including git commit id):
    v23.03-0f9488ace
  • Platform (i.e. Linux distro, Docker, PHP, PostgreSQL, etc) versions:
    Debian 11 (bullseye), Docker 23.0.1, PHP Version 8.1.16, PostgreSQL 14
2

unfortunately, i don’t think this would work properly at the moment because some redirects tt-rss does don’t take port into account.

i never bothered to fix it because hosting stuff on random ports is so passé, iykwim. :slight_smile:

e: before you ask, i have no idea how annoying this would be fix.

3

Got it, I will redirect on the reverse-proxy in the meantime.

hosting stuff on random ports is so passé, iykwim :slight_smile:

True, but it lowers the amount of logs and script kiddy attempts, so I thought why not :stuck_out_tongue:

Anyway, thanks for the quick reply!

4

i managed to login on my test environment on a custom port, so this works, kinda.

OTP redirect seems to be breaking it tho. do you use OTP?

5

this works, kinda

Yes, it is not a major issue, but was worth a post :slightly_smiling_face:

do you use OTP?

Yes.

6

https://dev.tt-rss.org/tt-rss/tt-rss/pulls/105/files

@wn_name what do you think? i couldn’t figure out the underlying cause. (web-nginx? idk)

7

Without OTP all I needed to do was make sure (my frontend) nginx was passing the port back as part of Host and update TTRSS_SELF_URL_PATH.

With OTP enabled, after providing the OTP and submitting I noticed a 302 redirect to /tt-rss, followed by 301 redirect /tt-rss/. Looks like Auth_Internal::authenticate() (when OTP is enabled and the form needs displaying) is double-encoding $return and causing Handler_Public::login() to always redirect to Config::get_self_url() (which strips any trailing slashes, i.e. $SITE/tt-rss).

I can’t reproduce the issue with my setup, but maybe this would work (although maybe not with just blindly adding a slash-- didn’t dig into all scenarios):

diff --git a/plugins/auth_internal/init.php b/plugins/auth_internal/init.php
index f113cd31e..697d0d0d2 100644
--- a/plugins/auth_internal/init.php
+++ b/plugins/auth_internal/init.php
@@ -36,7 +36,7 @@ class Auth_Internal extends Auth_Base {
                                                return false;
 
                                } else {
-                                       $return = urlencode($_REQUEST["return"]);
+                                       $return = urlencode(with_trailing_slash($_REQUEST["return"]));
                                        ?>
                                        <!DOCTYPE html>
                                        <html>
@@ -81,7 +81,7 @@ class Auth_Internal extends Auth_Base {
                                                        <body class="flat ttrss_utility otp css_loading">
                                                                <h1><?= __("Authentication") ?></h1>
                                                                <div class="content">
-                                                                       <form dojoType="dijit.form.Form" action="public.php?return=<?= urlencode(with_trailing_slash($return)) ?>" method="post" class="otpform">
+                                                                       <form dojoType="dijit.form.Form" action="public.php?return=<?= $return ?>" method="post" class="otpform">
 
                                                                                <?php foreach (["login", "password", "bw_limit", "safe_mode", "remember_me", "profile"] as $key) {
                                                                                        print \Controls\hidden_tag($key, $_POST[$key] ?? "");
8

ah, double encoding? i’ll take a look at this again tomorrow, thx

9

i finally had some time to poke at this but naturally i had to fork fucking bitwarden extension first because it decided to warn me about plain HTTP with no way to disable it.

anyway, thanks to @wn_name noticing double-urlencode, i managed to make a much cleaner diff:

https://dev.tt-rss.org/tt-rss/tt-rss/commit/563675de095fef98a8eb2fc7b948845b6a693eb5

i’ve also noticed this behavior a while ago but this gave me motivation to fix it and unfuck a few things in the process. thanks op.

also, looks like this whole trailing slash thing is nothing new. why is this needed though remains a mystery. :thinking:

1 Like
10

Thank you both for your work fixing this :slight_smile:

@fox Good luck with Bitwarden, I hope they fix issues like this soon and don’t require users to fork because of them.