Making the downloader public when enabling the multi-user mode

[ibrahimk157]

Hello,

As suggested, I created a new separate issue for this continuing from https://github.com/Tzahi12345/YoutubeDL-Material/issues/303

With the current multi-user authentication system, if enabled, all users need to authenticate even to just access the downloader itself.

However, what I wanted was a similar functionality to the previous pin-based system, which is to just lock the settings behind some sort of authentication system, while not requiring any authentication for the downloader itself.

@GlassedSilver made a great point on how adapting the existing authentication system to have an optional toggle for this, which would do the job perfectly!

Thanks!

[GlassedSilver]

My relevant suggestion as posted here to keep the discussion trackable within a single issue. :)

I'm not sure having two separate authentication systems in place really helps things.

Ideally we'd have the authentication system that we do atm and then a setting to make downloads by users public or not. Ideally on a case-by-case basis. Of course, you could set user defaults and have all of your downloads public by default and whenever you download something you want to keep private you could have that set as private individually.

That way you could reap the benefits of both a public approach and a full authentication system.

I'll be honest with you though, I won't be able to work on this, at least not anytime soon. I'll ping @Tzahi12345 to invite him into this discussion, although if you don't mind that might be better off to be made an issue of its own.

Multi-issues are usually best left to track the progress of individual issues' progress and when they are closely related to another or even blocking among themselves. (i.e. one thing needs to be done to take care of another issue)

[Tzahi12345]

I really like this idea -- and I do appreciate that with the old pin system there was a public facing page with admin settings hidden behind authentication. Now there's no such option.

This isn't a small task in that a lot of the current infrastructure would have to be changed to support a feature like this. The easier part of this is having downloads that are public or hidden behind an account. The harder component is to support the 3 authentication models:

• Option 1: No auth, just public (like how it is now without multi-user mode)
• Option 2: Public facing page with optional login for user-specific videos
• Option 3: Hiding all content behind user accounts (like how it is now with multi-user mode)

The code can already get messy with just 2 of those models. Just for illustration these are the checks we'd have to do if someone wants to access a video:

1. Check if they're logged in or not
2. Check which option we're using
3. Check if the video is public if option 2 is being used
4. Check if the video has sharing enabled if option 3 is being used

Here's the current authentication logic, though it branches out into some of the function calls within optionalJwt()

It can certainly be expanded, but I do want to explore this idea further so that we can come up with a robust solution. I think for permissions we can roll that into our existing framework by creating a "guest" role that applies to non-logged in users. I'm a bit tired and sick so hopefully some of this makes sense.

[ibrahimk157]

I really like this idea -- and I do appreciate that with the old pin system there was a public facing page with admin settings hidden behind authentication. Now there's no such option.

This isn't a small task in that a lot of the current infrastructure would have to be changed to support a feature like this. The easier part of this is having downloads that are public or hidden behind an account. The harder component is to support the 3 authentication models:

• Option 1: No auth, just public (like how it is now without multi-user mode)
• Option 2: Public facing page with optional login for user-specific videos
• Option 3: Hiding all content behind user accounts (like how it is now with multi-user mode)

The code can already get messy with just 2 of those models. Just for illustration these are the checks we'd have to do if someone wants to access a video:

1. Check if they're logged in or not
2. Check which option we're using
3. Check if the video is public if option 2 is being used
4. Check if the video has sharing enabled if option 3 is being used

Here's the current authentication logic, though it branches out into some of the function calls within optionalJwt()

It can certainly be expanded, but I do want to explore this idea further so that we can come up with a robust solution. I think for permissions we can roll that into our existing framework by creating a "guest" role that applies to non-logged in users. I'm a bit tired and sick so hopefully some of this makes sense.

I really appreciate you always considering users’ feedback/suggestions! Can’t thank you enough!

P.s. Get well soon!