Seer integration, working prototype, and a question about authentication

[HexS2]

Hello,

First of all I'd like to thank the team for making Litefin. I have a Tizen 5.0 TV and it's one of the only apps that runs smoothly on it!

I've built a Jellyseerr integration for Litefin and it's running on my TV.

Right now the Jellyseerr integration has the basics: a Discover page that pulls trending, popular movies and popular series from a Jellyseerr instance, searches its catalogue, and submits requests, including per-season requests for series. Status badges show what's already requested or available.

The sidebar entry stays hidden until an instance is configured, so the feature is completely invisible and makes no network calls for anyone not running Jellyseerr.

This is what I'd like your opinion on.

The obvious design is: the user signs in with their Jellyfin credentials, exactly like Jellyseerr's own web UI. I implemented that first.

POST /api/v1/auth/jellyfin succeeds — 200, and it sets the connect.sid session cookie. But the cookie carries HttpOnly; SameSite=Lax, and Litefin is served from file://, so its origin is null. Every request to the instance is therefore cross-site, and a SameSite=Lax cookie is never attached to a cross-site request.

Tested on my Tizen 5.0 TV (Chromium 63): login returns 200, and the very next GET /auth/me returns 401. I get the same result over HTTPS behind a reverse proxy and over plain HTTP straight to a LAN address, so it isn't TLS or the proxy. The app runs from file:///opt/usr/apps/... it shows up in the stack traces so its origin is null and every call to the instance counts as cross-site, which is exactly when a SameSite=Lax cookie is withheld.

I can't work around it from JavaScript: Cookie is a forbidden request header and Set-Cookie is a forbidden response header, so I can neither send the cookie myself nor read it and it's HttpOnly on top of that.

Going through the OpenAPI spec, securitySchemes declares exactly two schemes, cookieAuth and apiKey, so there's no per-user token to fall back on. Quick Connect looked promising, but /auth/jellyfin/quickconnect/authenticate "creates a user session" and returns a User, so as far as I can tell it lands on the same cookie I didn't test that one end to end.

So right now I've gone with the API key that Jellyseerr provides, and it works fine, but a Jellyseerr API key is instance-wide and admin-scoped, which raises two fair objections.

• Requests would all be credited to whoever owns the key. To fix that I added a "Request as" row to the settings tab, where the viewer picks their account from a list POST /request accepts a userId, so requests are credited to them against their own quota.
• A non-admin can't obtain the key. No fix for this one. In practice whoever sets up the TV is usually whoever administers the server, and they only enter it once but it's a real limitation and I'd rather say so than hide it.

There's also a UX problem: a Jellyseerr API key is about 68 characters, and typing that on a remote is hell. I made the field unmasked so at least a typo can be spotted, and it's validated immediately on save, but I haven't found a way to make the entry itself less painful.

So, three things I'd like your opinion on:

1. Would you be interested in a PR for this?.
2. Is storing an admin-scoped API key acceptable for this project ?
3. Any idea for the seer login that I might have missed ?

Either way, thanks for the app and happy to rework or reshape this into whatever fits the project.

EDIT: I saw this issue: #279 (comment), and right now, I think the best way to authenticate with Seer is to use the Litefin plugin, like Moonfin does. Using Jellyfin Enhanced's API seems limited.

[MoazSalem]

@HexS2 impressive work, i will try to look into login issues you raised as they seem like issues i will face once i will start the implementation,
but overall i think i will take a different approach to what you are doing, it will be a Seerr sidebar entry that will open a homepage with rows, like the Seerr ui, and every item will open a details page of it's own, that has the request and add to watch list buttons obviously, and i will use the plugin to let the user add thier Seerr server url, and then shape my own responses through it so it works seamlessly with the current UI components of litefin, i do see that i am still missing where the search will be not sure if i am missing any other features of Seerr ?

So, to answer your questions:

1- I think i will start a bigger implementation with the Litefin plugin, so i am sorry, but the PR will cause more issues i think.
2- It might be if it's the only way, but i think there is a better solution than that.
3- Not sure, but i might take a look at how Moonfin is doing it.

I thank you for this detailed implementation, honestly, if you told me before i did the Litefin plugin, we might have merged your implementation.

[HexS2]

Hey :) I’ve started working on the Litefin plugin, as I don’t think having the API key directly in the TV client is a good idea.

I’ve managed to connect to my Seerr server through the Litefin plugin. This means that, on the Litefin client side, no additional login is required as long as the Litefin plugin is properly configured in Jellyfin.

I’ll have to rewrite part of the client-side code to remove the API key login and the related authentication logic.

I also think having a dedicated details page when clicking on a movie or TV show is a really good idea. That’s something I haven’t implemented, currently, clicking on an item just opens a popup where you can request it. A proper details page with the request/watchlist actions would definitely integrate better with the rest of Litefin.

Regarding other Seerr features, one that comes to mind is request management, where admins can view, approve, or decline requests. However, I’m not sure it would be worth implementing that in Litefin, since it’s really an admin-only feature. For regular users it wouldn’t provide much value, so I think keeping the integration focused on browsing, searching, requesting, and managing the user’s own requests/watchlist would make more sense.

[HexS2]

Hey again! Here’s a quick update on what I’ve managed to implement since my previous message.

The server-side integration is now working, and I’ve also reworked the client-side implementation around it. The Seerr URL and API key are configured once by the Jellyfin administrator in the Litefin plugin, so no additional login or credentials are required on the TV.

The client now communicates exclusively with the Litefin plugin through the user’s existing Jellyfin session. The plugin then communicates with Seerr on the user’s behalf, while keeping the API key entirely on the server and never exposing it to the client.

The plugin also matches the authenticated Jellyfin user with their linked Seerr account and uses Seerr’s X-API-User header. This ensures that requests and watchlist actions are attributed to the correct user while respecting their Seerr permissions, quotas, and approval rules.

When the Litefin plugin is installed and successfully connected to Seerr, the Seerr settings section looks like this:

When the plugin is missing, not configured, or unable to reach Seerr, the integration is shown as unavailable:

Once connected, a dedicated Discover entry becomes available in the Litefin sidebar:

Opening it displays a dedicated discovery page with trending content, popular movies, and popular TV shows. A search bar is also available for searching the Seerr catalogue.

Selecting a card opens a dedicated details page using the existing Litefin design. From there, users can request the title or add it to their Seerr watchlist.

Selecting Request opens a TV-friendly request dialog. Users with the appropriate Seerr permissions can select one of their configured Radarr or Sonarr servers, a quality profile, and a root folder.

For TV shows, the dialog also allows users to select individual seasons while preventing seasons that are already available or already requested from being selected again.

I have tested the plugin with Jellyfin 10.11.11, .NET 9, and Seerr 3.4.1. The Normal client build completes successfully, and I have also tested the Normal package on my Tizen 5.0 TV, where it runs smoothly. I’ll continue testing it and addressing any issues I find.