-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
login_only #3728
base: master
Are you sure you want to change the base?
login_only #3728
Conversation
Don't push other changes that have nothing to do with the feature. You have added docker related things |
Sorry, this is my first time submit PR, meanwhile I am learning CI/CD things. |
Would you please review it again, thank you. |
Thanks for the PR, and sorry for the delay it took me to review. This subject is a tough one: By adding that check at the bottom of Ideally, we should use a local cache to store user sessions (see the kemalcr/kemal-session shard), so that we don't have to call the DB all the time on every request. |
bump? |
Sorry for late reply, I have updated the code before "return if (line 64)", please review, thank you. |
I built the patch from this specific pull request and its working: rix1337/docker-utube/general (arm image only) Its broken however on the popular iOS client Yattee (even if logged in inside the app): To help understand the error, I built Yattee locally and debugged the request that causes the it: requestDescription String "GET https://HOSTNAME/api/v1/videos/e50028LAtAo" This requests results in a http 500 error with the patch applied. This is easily reproducible by requesting the URL when logged out: When logged in, there is no 500 error. I therefore assume, this patch is working correctly. To work with this new parameter, Yattee needs to request the videos Endpoint with the session cookie. |
Also the health check from docker compose has now switched to unhealthy permanently:
This endpoint should probably be replaced by another one, that response properly even when logged out. Any suggestions? |
Related Yattee issue: yattee/yattee#552 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please release. Was looking forward to this.
thank you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change appears functionally good to me, except it does introduce an unhanded error when loading the loading page whilst not logged in:
2023-11-09 14:59:59 UTC [info] 302 GET / 441.37µs
Exception: Closed stream (IO::Error)
from /usr/share/crystal/src/io.cr:121:5 in 'check_open'
from /usr/share/crystal/src/compress/gzip/writer.cr:74:15 in 'write'
from /usr/share/crystal/src/http/server/response.cr:97:7 in 'write'
from /usr/share/crystal/src/io.cr:484:7 in 'write_string'
from /usr/share/crystal/src/string.cr:5263:5 in 'to_s'
from /usr/share/crystal/src/io.cr:177:5 in '<<'
from /usr/share/crystal/src/io.cr:191:5 in 'print'
from src/invidious/helpers/handlers.cr:40:5 in 'process_request'
from lib/kemal/src/kemal/route_handler.cr:17:7 in 'call'
from /usr/share/crystal/src/http/server/handler.cr:30:7 in 'call_next'
from lib/kemal/src/kemal/websocket_handler.cr:13:14 in 'call'
from /usr/share/crystal/src/http/server/handler.cr:30:7 in 'call_next'
from lib/kemal/src/kemal/filter_handler.cr:21:7 in 'call'
from /usr/share/crystal/src/http/server/handler.cr:30:7 in 'call_next'
from src/invidious/helpers/handlers.cr:212:5 in 'call'
from /usr/share/crystal/src/http/server/handler.cr:30:7 in 'call_next'
from src/invidious/helpers/handlers.cr:94:12 in 'call'
from /usr/share/crystal/src/http/server/handler.cr:30:7 in 'call_next'
from src/invidious/helpers/handlers.cr:145:12 in 'call'
from /usr/share/crystal/src/http/server/handler.cr:30:7 in 'call_next'
from src/invidious/helpers/handlers.cr:70:5 in 'call'
from /usr/share/crystal/src/http/server/handler.cr:30:7 in 'call_next'
from src/ext/kemal_static_file_handler.cr:162:16 in 'call'
from /usr/share/crystal/src/http/server/handler.cr:30:7 in 'call_next'
from lib/kemal/src/kemal/exception_handler.cr:8:7 in 'call'
from /usr/share/crystal/src/http/server/handler.cr:30:7 in 'call_next'
from src/invidious/helpers/logger.cr:17:35 in 'call'
from /usr/share/crystal/src/http/server/handler.cr:30:7 in 'call_next'
from lib/kemal/src/kemal/init_handler.cr:12:7 in 'call'
from /usr/share/crystal/src/http/server/request_processor.cr:51:11 in 'process'
from /usr/share/crystal/src/http/server.cr:517:5 in 'handle_client'
from /usr/share/crystal/src/http/server.cr:470:13 in '->'
from /usr/share/crystal/src/fiber.cr:146:11 in 'run'
from /usr/share/crystal/src/fiber.cr:98:34 in '->'
from ???
2023-11-09 14:59:59 UTC [info] 302 GET /feed/popular 10.91ms
2023-11-09 14:59:59 UTC [info] 200 GET /login 839.7µs
@@ -84,6 +84,7 @@ class Config | |||
|
|||
# Used to tell Invidious it is behind a proxy, so links to resources should be https:// | |||
property https_only : Bool? | |||
property login_only : Bool? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be good to add a descriptive comment on what this does, similar to the others.
One more thing I noticed. When using a third-party client like Yattee. Adding the instance and logging into an account is only possible when |
@@ -100,6 +88,24 @@ module Invidious::Routes::BeforeAll | |||
end | |||
end | |||
|
|||
unregistered_path_whitelist = {"/", "/login", "/licenses", "/privacy"} |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
This unhandled exception also happens when logged in. |
unregistered_path_whitelist = {"/", "/login", "/licenses", "/privacy"} | ||
if CONFIG.login_only && !env.get?("user") && !unregistered_path_whitelist.includes?(env.request.path) |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is good, but I also found that Clipious client requires /api/v1/stat
when adding a new server to the client. It loads this to check it is a valid server, and refuses if it doesn't work (currently it returns a 500 error, which should be a bug anyway). However, even if this additional endpoint is added the client doesn't load Popular and Trending (default pane) because it makes these requests unauthenticated (will need to raise this as an issue with Clipious)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added your input to a new suggestion.
unregistered_path_whitelist = {"/", "/login", "/licenses", "/privacy"} | ||
if CONFIG.login_only && !env.get?("user") && !unregistered_path_whitelist.includes?(env.request.path) | ||
env.response.headers["Location"] = "/login" | ||
haltf env, status_code: 302 | ||
end |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Third party apps using the API are depending on some endpoints being unauthenticated such as /api/v1/popular and /api/v1/trending, currently there are giving a 500 error (but no traceback), and I haven't investigated the cause. These endpoints in https://github.com/iv-org/invidious/tree/master/src/invidious/routes/api/v1 are divided between Authenticated and others, where the others are implied to be Public. I tried adding authentication headers to the requests in Clipious, but the server side component doesn't seem to be expecting auth'. Whilst adding "/api/v1/stats" facilitates login, the actual app' isn't really functional. So I think we state that |
Well, these two endpoints could be added to the whitelist as well. Since video playback still wouldn't be possible without logging in. |
True, I assumed the intent of login was to reduce data leak... but popular and trending isn't really sensitive. |
Just adding that after I raised my issue with Yattee they were able to quickly produce a fix, so your findings may be isolated to Clipious. The patch from this pr works perfectly in combination with the patch from Yattee, when I enable login_only. |
I added them to the suggestion, as @rix1337 pointed out, Yattee does show the Trending and Popular (if enabled) when |
env.response.headers["Location"] = "/login" | ||
haltf env, status_code: 302 |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
@@ -84,6 +84,7 @@ class Config | |||
|
|||
# Used to tell Invidious it is behind a proxy, so links to resources should be https:// | |||
property https_only : Bool? | |||
property login_only : Bool? |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This is a modification of PR iv-org#3728. And addresses iv-org#446 Server admins can set the instance to be private. Which means it is only accessible with a registered user account. The endpoints `/api/v1/popular` and `/api/v1/trending` are whitelisted because some clients expect them to be open.
I opened a separate PR (#4259), where I address all the missing bits of this one. |
That would be a cool feature to have! Yattee for instance doesn't support basic auth |
This pull request has been automatically marked as stale and will be closed in 30 days because it has not had recent activity and is much likely abandoned or outdated. If you think this pull request is still relevant and applicable, you just have to post a comment and it will be unmarked. |
This pr is still very much relevant |
Invidious is great software, just discovered it. I'm a YouTube Premium user who can't stand all the extras and autoplay and visual noise any more (even Premium isn't enough). Please guys make Invidious for logged in users only. We are running it on a small VPS and if even a small group of five people were to come and start watching 4K videos, our VPS would collapse. At this point, having read the related issue and the [other commits](#4259, it seems more a question of ill-will than a technical obstacle. What I mean by ill-will is that some of the core developers don't believe that creating private Invidious instances should not be easy. Yes, I know about the http auth alternative but that effectively creates double login. I might be able to get by with whitelisted IP's but it's all a barrier to use, which a simple login barrier would be enough to solve. That someone's stats program won't work when logged-in does not seem relevant. Mr Stats could just work on his own patch or not use the logged-in only feature. Why don't you make logged-in only a paid feature? I'd happily pay $20 to support the project and to have this option. Yes, I could code it myself or hand apply these patches. But that doesn't help the project or others. It just means a whole lot of wasted duplicate effort. |
@@ -100,6 +88,24 @@ module Invidious::Routes::BeforeAll | |||
end | |||
end | |||
|
|||
unregistered_path_whitelist = {"/", "/login", "/licenses", "/privacy"} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think /videoplayback
needs to be added, otherwise I was not able to watch videos (DASH).
This is a modification of PR iv-org#3728. And addresses iv-org#446 Server admins can set the instance to be private. Which means it is only accessible with a registered user account. The endpoints `/api/v1/popular` and `/api/v1/trending` are whitelisted because some clients expect them to be open.
There are some news about this implementation? |
PR refer to #446