[Feature request] private invidious

johnwmail commented 5 years ago

Hi, is it possible config invidious only allow watch/listen video for logged in user? Thanks.

ghost commented 5 years ago

I don't think this feature exists but you can add a simple rule to disallow users which are not logged in. (@omarroth) This might be good feature request, some admins may want to restrict viewing to logged in users only.

johnwmail commented 5 years ago

Hi, how to add "simple rule disallow users which are not logged in"? thanks.

Perflyst commented 5 years ago

What can not logged in users on such instances do? Why do you not just add a simple http auth?

johnwmail commented 5 years ago

What can not logged in users on such instances do? Why do you not just add a simple http auth?

Maybe just see the login page(input username and password).
Because http auth can not use cookie, and need to login everytime. Thanks.

ghost commented 5 years ago

I don't know the language invidious is written in, maybe look for code where it checks if user is logged in and remove everything for else block and print you must be logged in :?

You can also make it a Tor hidden service and protect it. See https://tor.stackexchange.com/questions/13416/how-does-hiddenserviceauthorizeclient-work, https://2019.www.torproject.org/docs/tor-manual.html.en, https://matt.traudt.xyz/p/FgbdRTFr.html & https://riseup.net/en/security/network-security/tor/onionservices-best-practices

look for HiddenServiceAuthorizeClient

omarroth commented 5 years ago

Something like:

diff --git a/src/invidious.cr b/src/invidious.cr
index f93f17e..74b2a8e 100644
--- a/src/invidious.cr
+++ b/src/invidious.cr
@@ -231,6 +231,12 @@ before_all do |env|
   end

   env.set "current_page", URI.escape(current_page)
+
+  unregistered_path_whitelist = {"/", "/login", "/licenses", "/privacy"}
+  if !env.get?("user") && !unregistered_path_whitelist.includes?(env.request.path)
+    env.response.headers["Location"] = "/"
+    halt env, status_code: 302
+  end
 end

 get "/" do |env|

Should produce the desired functionality.

You can modify the unregistered_path_whitelist as necessary, and the env.response.headers["Location"] = "/" to redirect all pages to e.g. /login.

I don't see something like this being merged into master since it's not very privacy friendly and I'm having trouble seeing a large enough use case to justify including it as a feature.

johnwmail commented 5 years ago

licenses

Hi, It work with redirect to /login for me, thanks.

one more question, how to whitelist path like: "/vi/XU7YV1tWr10/mqdefault.jpg" ? I mean all path under "/vi". ("/vi/*/*.jpg" or is it support RE/glob?)

Thank you.

johnwmail commented 5 years ago

Hi, sorry to say that, but would you please reconsider it again. I create a new patch login_only.diff.txt to let it configurable and tune off by default, thanks.

` diff -urN ./src/invidious/helpers/helpers.cr ../invidious/src/invidious/helpers/helpers.cr --- ./src/invidious/helpers/helpers.cr 2019-04-04 08:05:20.762351942 +0000 +++ ../invidious/src/invidious/helpers/helpers.cr 2019-04-04 08:04:53.362400529 +0000 @@ -83,6 +83,7 @@ ), full_refresh: Bool, # Used for crawling channels: threads should check all videos uploaded by a channel https_only: Bool?, # Used to tell Invidious it is behind a proxy, so links to resources should be https://

login_only: Bool?, # Allow logged in user only? hmac_key: String?, # HMAC signing key for CSRF tokens and verifying pubsub subscriptions domain: String?, # Domain to be used for links to resources on the site where an absolute URL is required use_pubsub_feeds: {type: Bool, default: false}, # Subscribe to channels using PubSubHubbub (requires domain, hmac_key) diff -urN ./src/invidious.cr ../invidious/src/invidious.cr --- ./src/invidious.cr 2019-04-04 08:05:20.762351942 +0000 +++ ../invidious/src/invidious.cr 2019-04-04 08:04:53.362400529 +0000 @@ -233,6 +233,12 @@ end

env.set "current_page", URI.escape(current_page)
unregistered_path_whitelist = {"/", "/login", "/licenses", "/privacy"}
if !env.get?("user") && !unregistered_path_whitelist.includes?(env.request.path) && config.login_only
env.response.headers["Location"] = "/login"
halt env, status_code: 302
end end

get "/" do |env|

`

omarroth commented 5 years ago

one more question, how to whitelist path like: "/vi/XU7YV1tWr10/mqdefault.jpg" ?

If you want globbing, it would probably be best to move it into middleware, something like this.

I'm against adding this since it would mean supporting a feature that is user-specific or be used by a very, very small number of administrators. Additionally, requiring that users register with the instance in order to use it is not privacy-friendly.

If there's more requests to support something like this I'll consider adding it.

johnwmail commented 5 years ago

If there's more requests to support something like this I'll consider adding it. Ok, fair enough, thank you.

omarroth commented 5 years ago

Reopening since some other folks have expressed interest in this feature.

tleydxdy commented 5 years ago

perhaps add tokened links to still allows sharing with friends

PureTryOut commented 4 years ago

Yeah I definitely want this feature. I'd like to keep my instance private to myself and maybe some friends and family, so to prevent anyone from accidentally finding the instance and using it to watch videos, I'd like to restrict that functionality behind a login. Also like @johnwmail said, a properly supported method in Invidious itself rather than proxy authentication is preferred due to cookies, usability, etc.

If you're not logged in, you should probably just be redirected to the login page.

ChairmanMkay commented 4 years ago

@PureTryOut

Grab referer? Allow from webmail and friend domains. No basic auth. Then cookie them.

LennyPenny commented 4 years ago

I would love this feature as well to run a cheap instance for my friends while keeping dash playback and subscription feed performance high. Also that dmca_content config option is pretty scary when running this for friends

TheFrenchGhosty commented 4 years ago

@LennyPenny Set it behind an HTTP login

github-actions[bot] commented 3 years ago

This issue has been automatically marked as stale and will be closed in 30 days because it has not had recent activity and is much likely outdated. If you think this issue is still relevant and applicable, you just have to post a comment and it will be unmarked.

syeopite commented 3 years ago

Bump

cocoonkid commented 3 years ago

+1

bigOconstant commented 2 years ago

+1

cocoonkid commented 2 years ago

I solved this by putting authelia in front. And whitelisting IP's for cases of clients other than web.

bigOconstant commented 2 years ago

I solved this by putting authelia in front. And whitelisting IP's for cases of clients other than web.

I ended up just using basic auth in nginx https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-http-basic-authentication/

Works really well for just one person.

johnwmail commented 1 year ago

Hi, I re-created the new patch for same purpose (the old one cannot apply), thanks.

invidious-login_only.diff.txt

cazwacki commented 1 year ago

I'm someone who could get benefit from this concept. If this got turned into a PR, would it be accepted? I don't understand why patches are being created instead of full PRs.

unixfox commented 1 year ago

Everyone is free from submitting pull requests for new code changes, feel free to do it.

net00-1 commented 1 year ago

I'm also interested in this. Ideally I imagine it should be like FreshRSS. You would be only presented with a login screen, and then registrations could also be disabled to make sure only authorized accounts exist. Placing HTTP auth in front is not ideal, since a few applications that use Invidious API (e.g. Yattee) are not compatible as I've tested.

DanielLaberge commented 1 year ago

I would also like official support for this. Applying a patch manually is not really feasible when using the docker image.

Thank you for the consideration.

rix1337 commented 1 year ago

Judging by https://github.com/iv-org/invidious/issues/446#issuecomment-1493385420

all we need is the diff from https://github.com/iv-org/invidious/issues/446#issuecomment-1342296218 sent in and reviewed as a pull request.

I just created this pull request:https://github.com/iv-org/invidious/pull/4222 Hoping for a review and merge.

A (insecure, as its frontend-only) workaround for the time is setting the following environment variable in your docker compose:

version: "3"
services:
...
  invidious:
...
    environment:
...
        banner: "<script>document.querySelector('a[href*=\"/login\"]') && !location.pathname.startsWith('/login') && (location.href = '/login');</script>"

This requires removing/changing your CSP headers through a reverse proxy like nginx and is easily circumventable since it's handled purely by the browser/frontend. I would therefore HIGHLY appreciate a server-side solution.

Example using nginx as a reverse proxy:

        proxy_hide_header "Content-Security-Policy";

(again I advise against seeing this as a proper security measure)

rix1337 commented 1 year ago

Apparently there is already #3728 waiting to be merged with improvements to the patch.

iv-org / invidious

[Feature request] private invidious #446