jellyfin / jellyfin-roku

The Official Roku Client for Jellyfin
https://jellyfin.org
GNU General Public License v2.0
438 stars 133 forks source link

Parental controls busted: Search finds & plays all media, even media the current user shouldn't have access to. #1029

Closed iuy6tf57765fsegh5yhw45yuh8g4 closed 10 months ago

iuy6tf57765fsegh5yhw45yuh8g4 commented 1 year ago

Software Versions Jellyfin Server Version: 10.8.8 Roku Client Version: Jellyfin Roku 1.6.3

Describe the bug On Roku client, accessing the search appears to be unrelated to the user currently logged in. This means my children's account can be logged in, and if they start typing in a search, it will start showing results from the entire server, including adult material that is otherwise inaccessible to them through other Jellyfin clients. If you attempt to play media that the current user shouldn't have access to, it will play regardless.

This means that search on Roku bypasses all parental controls and user permissions in regards to media access.

How To Reproduce

  1. Set up a restricted user who only has access to a subset of your library
  2. Log into Roku Jellyfin app with the restricted user
  3. Perform a search for material that this user doesn't have access to
  4. Watch in horror as content you thought was inaccessible is available to anyone.

Expected behavior When you use a restricted user to search, the search results should be limited to media that the current user has permission to see.

iuy6tf57765fsegh5yhw45yuh8g4 commented 1 year ago

I see line 339 in Main.brs calls the SearchMedia function or method:

results = SearchMedia(query)

https://github.com/jellyfin/jellyfin-roku/blob/6336c87ea6778aa3281714bb49267f2538c657d2/source/Main.brs#L339

I'm going to locate SearchMedia() and see what I can find, but just updating this with what I hope is relevant information in the meantime.

EDIT:

SearchMedia() is located in /source/api/Items.brs line 37

https://github.com/jellyfin/jellyfin-roku/blob/6175d36046e837749453cbf64b0d82c2a8400dca/source/api/Items.brs#L37

EDIT2: Interesting. Looks like the API call is supposed to be passing the current user:

https://github.com/jellyfin/jellyfin-roku/blob/6175d36046e837749453cbf64b0d82c2a8400dca/source/api/Items.brs#L43

So either the user isn't populating here for some reason, or the API is ignoring the user on the other end. Well, I'm going to need to get a dev environment set up to go much further than this.

surepointit commented 1 year ago

Can confirm, and came here to report. Imagine my surprise when my parents did a random search and found the "other" media they weren't supposed to see. Can also play hidden media, but media does not show in recently watched, which is probably a good thing.

However, replaying a content asks if you want to resume where you left off, so it's caching that info. And when that user is playing the hidden content, you can see that playing in the admin section of the server.

The Roku app is version 1.6 build 3.

Doesn't appear to be broken on web site. Have logged in with a restricted user and search in the browser doesn't show unexpected results.

Also tested with Jellyfin app on Android and search results are as expected.

My Jellyfin server version is 10.8.9 too.

cewert commented 1 year ago

Yea, that's weird. Apparently the Search/Hints API endpoint doesn't respect the userId provided. Maybe that's why the web client started using the Items API endpoint instead like the comments say? Maybe a bug on server side?

function searchMedia(query as string)
    ' This appears to be done differently on the web now
    ' For each potential type, a separate query is done:
    ' varying item types, and artists, and people

Either way, I think if we rewrite search to use the Items endpoint, like how the web client did it, that would fix this problem. It's going to be a lot of work though :(

lagerea commented 10 months ago

I came for this too, I found out when I had set up a restricted account for my neighbor, and doing a search he found my girlfriend, and I's personal recordings. A temporary workaround because the search doesn't allow for special characters would be to rename all the suspect files with a special character, but that is a hell of a workaround.