External linking to overseerr page

jankowski-piotr commented 11 months ago

Description

There is some unexpected redirect (307 Temporary Redirect (from service worker) when clicking a href element from another tab. When clicking a link: https://instance/tv/0000 short login page appears and it redirects to main page. The link has no referrals. Directly pasting url to browser works.

Version

1.33.2

Steps to Reproduce

Click a href element on different site.
Observe it redirects to main page.

Screenshots

No response

Logs

No response

Platform

desktop

Device

PC

Operating System

Windows 11

Browser

Chrome/Firefox

Additional Context

No response

Code of Conduct

[X] I agree to follow Overseerr's Code of Conduct

JFizDaWiz commented 11 months ago

can confirm, I use a tampermonkey script that scrapes the IMDB URL and adds an Overseerr icon on the page that links to

{base URL}:{port}/search?query=imdb:tt0060345

when I copy/paste the URL it works but clicking the link flashes login page then back to main page.

jankowski-piotr commented 11 months ago

Basically none of externally clicked link is working. Nothing that launches browser or opens a new tab. Same goes for notifications on any OS.

daniel-l commented 9 months ago

Adding to this:

Clicking on links injected via a userscript (e.g. a link to the overseerr search injected on imdb.com: http://:5055/search?query=Monty%20Python%20and%20the%20Holy%20Grail) redirects not to overseerr's search/search results page but first to the login page and than automatically - if already logged in - to the main page.
When the inserted link is copied instead and then pasted into the browser bar the login page is skipped and overseerr's search results page open, in case of the link above with the result for Monty Python and the Holy Grail.

maodun96 commented 7 months ago

I have also encountered similar situations, but now my iPad (Safari) can avoid this issue: it won't be redirected to the login page. However, my technical knowledge is limited, and I don't know how it works in the background.

maodun96 commented 7 months ago

I have also encountered similar situations, but now my iPad (Safari) can avoid this issue: it won't be redirected to the login page. However, my technical knowledge is limited, and I don't know how it works in the background.

Only my iPad can avoid such situations. My Windows 10 and iPhone both get redirected to the login page.

maodun96 commented 7 months ago

I have also encountered similar situations, but now my iPad (Safari) can avoid this issue: it won't be redirected to the login page. However, my technical knowledge is limited, and I don't know how it works in the background.

I have discovered a perplexing reason.

I pinned the tabs of the Homarr app in Safari and opened an external link related to Overseerr from one of those tabs: http://instance/tv/0000. At this point, the bug of being redirected to the Overseerr login page no longer occurs.

By inspecting the network traffic, I observed that the GET request to http://instance/tv/0000 contained cookie information. Previously, this information did not exist. Instead, it was present in the subsequent GET request to http://instance/site.webmanifest. The GET request to http://instance/login occurred between these two requests.

Parlane commented 5 months ago

Hello all,

I had this same problem as I was trying to get homeassistant notifications to follow directly to the url of the request but it would always take me through /login and then to the index page instead of the requested page /movie/1026999.

Looking at nginx logs it was very obvious that chrome on android was not sending the Cookies: header for the request, hence the 307 redirect to /login, but because at this point the /login page successfully gets the Cookie: header from the browser then the login is successful and redirects again to /

The fix can be done via nginx reverse proxy config (requires signing out and logging back in to overseerr as the samesite flag is only sent whent he cookie is first created):

proxy_cookie_flags ~ samesite=Lax;

This changes the Set-Cookie header to use samesite=Lax instead of samesite=Strict and allows chrome to send the Cookie when the /movie/1026999 URL is clicked from an external source such as another site or in my case a homeassistant notification.


Before:
Set-Cookie: connect.sid=my-secret-cookie; Path=/; Expires=Sun, 21 Jul 2024 01:36:20 GMT; HttpOnly; SameSite=Strict

After:
Set-Cookie: connect.sid=my-secret-cookie; Path=/; Expires=Sun, 21 Jul 2024 01:36:20 GMT; HttpOnly; SameSite=Lax; Secure

Anyway this seems to be the design for strict SameSite cookies, probably to prevent XSS attacks.

Matthew

edit: secure was not needed in proxy_cookie_flags so I edited it out.

maodun96 commented 5 months ago

Hello all,

I had this same problem as I was trying to get homeassistant notifications to follow directly to the url of the request but it would always take me through /login and then to the index page instead of the requested page /movie/1026999.

Looking at nginx logs it was very obvious that chrome on android was not sending the Cookies: header for the request, hence the 307 redirect to /login, but because at this point the /login page successfully gets the Cookie: header from the browser then the login is successful and redirects again to /

The fix can be done via nginx reverse proxy config (requires signing out and logging back in to overseerr as the samesite flag is only sent whent he cookie is first created):

proxy_cookie_flags ~ secure samesite=Lax;

This changes the Set-Cookie header to use samesite=Lax instead of samesite=Strict and allows chrome to send the Cookie when the /movie/1026999 URL is clicked from an external source such as another site or in my case a homeassistant notification.
Before:
Set-Cookie: connect.sid=my-secret-cookie; Path=/; Expires=Sun, 21 Jul 2024 01:36:20 GMT; HttpOnly; SameSite=Strict

After:
Set-Cookie: connect.sid=my-secret-cookie; Path=/; Expires=Sun, 21 Jul 2024 01:36:20 GMT; HttpOnly; SameSite=Lax; Secure
Anyway this seems to be the design for strict SameSite cookies, probably to prevent XSS attacks.

Matthew

p.s. not sure if "secure" is even needed.....

After capturing the packets, I also found that the problem was with cookies. But my technical level is not enough, so I directly switched to the jellyseerr project, which does not have this problem. Currently, jellyseer can use plex to log in, and I can't find any big difference between the two.

daniel-l commented 5 months ago

The fix can be done via nginx reverse proxy config (requires signing out and logging back in to overseerr as the samesite flag is only sent whent he cookie is first created):

proxy_cookie_flags ~ samesite=Lax;

This changes the Set-Cookie header to use samesite=Lax instead of samesite=Strict and allows chrome to send the Cookie when the /movie/1026999 URL is clicked from an external source such as another site or in my case a homeassistant notification.

Thanks for the input and investigation. Your solution might help others who set up a reverse proxy for internal domains etc. If you're not using a reverse proxy and instead rely on pure IP:Port another solution is editing your browser's cookie. In Firefox I just did this with the Add-On Cookie-Manager (https://cookie-editor.com, available for other browsers , too).

Steps:

Install Cookie-Manager
Open your Overseerr instance in your browser
Log in
Open Cookie-Manager (in Firefox it is part of your left sidebar)
open the "connect.sid" slide
Edit "Same Site" to "Lax" via the dropdown menu
Save the cookie with the adjacent Save-Button

Screenshot for reference: grafik

jankowski-piotr commented 5 months ago

@Parlane Great find. Now we can just amend session cookie setup in code, or introduce new option for proxy configurations.

sct / overseerr