Jellyseerr local login fails from web (proxmox helper script); works fine from android

[tismondo]

Description

I tried connecting my Fladder instance to Jellyseer via local IP using the web interface and keep getting the below error. The jellyseerr container is running and the same settings configured in the android app work fine, so I'm not sure if there's a bug here or user error.

I concede it's possible something specific about the LXC setup in proxmox is confusing things, but wanted to flag it.

Reproduction steps

1. Go to 'Settings > Profile > Advnaced'
2. Click on 'Seerr'
3. Input my working local IP (again - tested to be working via the Android app)
4. See error

Screenshots

No response

Logs

Platform

Web

App Version

0.9.0

Jellyfin server

Proxmox LXC

[divemasterjm]

+1

[Keyplayerone]

I am also receiving this specific error message. I discovered Fladder via Proxmox Helper scripts and find it very useful. However, the integration of Jellyseer did not work. Since I suspected a problem with helper scripts, I set up a separate Docker container - unfortunately, I encountered the exact same issue here.

[roormonger]

So from the digging I did, this is apparently a CORS problem. Using an API key will get it working in the web ui. Might be the only clean way...

[divemasterjm]

i've tried 3 methods, all give same error

[simon-dmsn]

Have you tried putting https (or http) at the beginning of the URL ? I had the same issue without and got it solved by adding https in front of my seer URL

If it can help :)

[tismondo]

Have you tried putting https (or http) at the beginning of the URL ? I had the same issue without and got it solved by adding https in front of my seer URL

My Jellyseerr is local-only and not behind tls but yes, I've tried http and https.

[PartyDonut]

So from the digging I did, this is apparently a CORS problem. Using an API key will get it working in the web ui. Might be the only clean way...

Yup this is a CORS error. This is not something I can fix in the Fladder web hosted version, you need Seerr to allow the connections comming from the Fladder host.

[Wunderharke]

So should this be raised in the seerr repo? Or is there already a configuration for this?
I added CORS headers manually at my reverse proxy, but now I get "No session cookie returned by server".
However, I can see it as request response. Maybe this is because it is HttpOnly?

EDIT:

Fladder/lib/screens/settings/widgets/seerr_connection_dialog.dart

Lines 206 to 210 in fec8451

	final cookie = await ref.read(seerrApiProvider).authenticateLocal(
	email: localEmailController.text.trim(),
	password: localPasswordController.text,
	headers: customHeaders.isEmpty ? null : customHeaders,
	);

HttpOnly cookies can not be red. This should rely on the returned HTTP status code and validate with /auth/me.
@PartyDonut sorry to revive this issue, but I think this is a real bug.

[PartyDonut]

@Wunderharke I'm not sure I follow the logic here.

The cookie is what we use to authenticate any other calls, we need that to make protected api calls.

How would relying on the status code and then calling using /auth/me work? From what I can tell /auth/me only returns the curent seerr user. We already need authentication at that point.

[Wunderharke]

When Fladder is deployed as a web app, Flutter compiles to JavaScript that runs inside the visitor's browser. Every HTTP request goes through the browser's own networking stack (fetch/XHR). This means the browser's security model applies unconditionally, and two of its rules directly break the current session-cookie flow:

1. set-cookie is a forbidden response header.
The browser processes set-cookie internally and filters it out before the response is exposed to JavaScript. This is enforced by the Fetch spec. See MDN. This cannot be bypassed by any library. _extractSessionCookie reads response.base.headers['set-cookie'], which will always be null on web — regardless of HttpOnly. This is why you get "No session cookie returned by server" even with CORS configured correctly.

2. Cookie is a forbidden request header.
Even if we somehow had the cookie string, setting Cookie: <value> manually in a request header would be silently stripped by the browser. So the current approach of storing the cookie and replaying it in SeerrRequest._authHeaders is fundamentally incompatible with the browser environment.

On native platforms (Android, iOS, desktop) there is no browser in the middle — the app makes raw TCP connections and can read and set any header freely. That is why the same code works on other platforms but not on web.

The correct approach for web

The browser already knows how to handle session cookies securely. The fix is to work with that rather than around it, using BrowserClient from package:http with withCredentials = true:

With this flag set, the browser automatically:

• Stores the session cookie from the login response
• Attaches it to every subsequent request to the same origin

No cookie string ever needs to be read, stored, or replayed manually.

However, three places in the code need to be conditioned on kIsWeb, not just the HTTP client construction:

Location	Problem on web	Fix
ChopperClient in seerr_api_provider.dart	Defaults to http.Client() with no credentials	Use BrowserClient()..withCredentials = true
_extractSessionCookie / authenticateLocal / authenticateJellyfin in seerr_service_provider.dart	Throws when cookie is null	On web: check response.isSuccessful only, store a sentinel value
_authHeaders in seerr_api_provider.dart	Tries to send Cookie header (stripped by browser)	On web: send nothing when no API key — browser handles it

The API key auth method (X-Api-Key header) is unaffected by any of this and will continue to work on web as long as CORS is configured, since it does not involve cookies.