[Feature request] private invidious

[johnwmail]

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

[ghost]

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]

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

[Perflyst]

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

[johnwmail]

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

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

[ghost]

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]

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]

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]

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]

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]

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

[omarroth]

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

[tleydxdy]

perhaps add tokened links to still allows sharing with friends

[PureTryOut]

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]

@PureTryOut

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

[LennyPenny]

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

[cocoonkid]

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

[bigOconstant]

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]

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

invidious-login_only.diff.txt

[cazwacki]

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]

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

[net00-1]

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.

[rix1337]

Judging by #446 (comment)

all we need is the diff from #446 (comment) sent in and reviewed as a pull request.

I just created this pull request:#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]

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

[syeopite]

For anyone that wishes to implement this feature do keep in mind that the before_all handler isn't actually called first in the Kemal middleware chain.

It's actually called last after all of the user defined ones.

Here's the order Kemal processes requests with

init handler
log handler
head request handler
error handlers
static file handler
custom handlers
filter handlers

web socket handlers
route handlers

The before_all handler is considered a filter handler and so is called right before the routes.