LinkStackOrg / LinkStack

LinkStack - the ultimate solution for creating a personalized & professional profile page. Showcase all your important links in one place, forget the limitation of one link on social media. Set up your personal site on your own server with just a few clicks.
https://linkstack.org
GNU Affero General Public License v3.0
2.37k stars 237 forks source link

Redirect behavior is different in Chrome vs Safari, potentially as a result of reverse proxy #165

Closed snicker closed 2 years ago

snicker commented 2 years ago

Given: using the docker container as an installation method,

a link configuration as such:

image

and a base url of https://links.helltoaster.scfs.me/ using nginx as a reverse proxy,

Clicking the link on the page with URL of: https://links.helltoaster.scfs.me/going/2/https://untappd.com/user/snicker/photos causes a redirect to this page: https://links.helltoaster.scfs.me/untappd.com/user/snicker/photos in Chrome, but not in Safari

Logs indicate that the redirect request to redirect()->away($link) is stripping the second slash on https://: [24/Sep/2022:17:09:51 +0000] "GET /going/2/https:/untappd.com/user/snicker/photos HTTP/1.1" 302 398

Safari seems to obey a malformed redirect request whereas Chrome does not.

snicker commented 2 years ago

It is not clear if this is because of the reverse proxy or not, but here is the proxy configuration:

        server_name links.helltoaster.scfs.me;
        location / {
            client_max_body_size 1024M;
            proxy_http_version 1.1;
            proxy_pass https://192.168.1.191:49153/;
            proxy_set_header                Host                    $host;
            proxy_set_header                X-Real-IP               $remote_addr;
            proxy_set_header                X-Forwarded-For             $proxy_add_x_forwarded_for;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
            proxy_cache off;
        }
snicker commented 2 years ago

Regardless of the cause, I believe that it is too implicit to redirect based on the request URL anyway, and the redirect request should come from the database anyway, based on the ID in the request URL.