Comments (12)
@nebula-it Thank you! Feel free to open up another issue if anything else crops up.
from youtubedl-material.
I think I just resolved this by adding a custom location to my NGINX config in line with your instructions for Nginx using Domain Subpath here. Does it make sense that I would have to do that even though I'm using a subdomain and not a subpath for my reverse proxy?
from youtubedl-material.
Glad you like the project so far :)
Regarding the error, I tried reproducing it with your config but I wasn't able to. If you open the console in the browser, do you see any errors? You can get to it by right clicking -> inspect element -> console. Maybe that will give us a hint as to what's going on.
Just out of curiousity, could the SSL params in /etc/nginx/conf.d/ssl-params.inc
be interfering in any way?
You may have checked this already, but does the docker container show any relevant errors? You can check this from the console, or view all logs in the appdata/logs
directory.
Definitely a weird error! Hopefully some more details will help. Let me know what you find.
from youtubedl-material.
I am experiencing the same issue. If I access via host IP:PORT it works fine, but if I access through my NGINX reverse proxy, some page elements don't load and I cannot access the settings dialog. When I access the page, I see two errors in the console:
{…}
error: "<html>\r\n<head><title>401 Authorization Required</title></head>\r\n<body bgcolor=\"white\">\r\n<center><h1>401 Authorization Required</h1></center>\r\n<hr><center>nginx</center>\r\n</body>\r\n</html>\r\n"
headers: Object { normalizedNames: Map(0), lazyUpdate: null, lazyInit: lazyInit() }
message: "Http failure response for https://ytdl.myurl.com/api/config: 401 Unauthorized"
name: "HttpErrorResponse"
ok: false
status: 401
statusText: "Unauthorized"
url: "https://ytdl.myurl.com/api/config"
<prototype>: Object { … }
1-es2015.d34e1e43126467f38c5b.js:1:851022
And then:
{…}
error: "<html>\r\n<head><title>401 Authorization Required</title></head>\r\n<body bgcolor=\"white\">\r\n<center><h1>401 Authorization Required</h1></center>\r\n<hr><center>nginx</center>\r\n</body>\r\n</html>\r\n"
headers: Object { normalizedNames: Map(0), lazyUpdate: null, lazyInit: lazyInit() }
message: "Http failure response for https://ytdl.myurl.com/api/config: 401 Unauthorized"
name: "HttpErrorResponse"
ok: false
status: 401
statusText: "Unauthorized"
url: "https://ytdl.myurl.com/api/config"
<prototype>: Object { … }
1-es2015.d34e1e43126467f38c5b.js:1:882843
UPDATE In the above, my NGINX proxy was set up to shield my youtubedl-material instance with basic auth. I removed the basic auth, but kept everything else the same, and the page renders fine. This issue seems to be related to basic auth on reverse proxy. I'm happy to help test possible solutions.
What I'm hoping to achieve is a youtubedl-material instance that is reverse proxied and protected from access by random strangers on the web, with a publicly exposed API that I can call from a remote location using my API key.
from youtubedl-material.
@crosbyhayton It sounds like your Authorization headers aren't being passed through. Does adding these lines to your location block fix the issue?:
proxy_set_header Authorization $http_authorization;
proxy_pass_header Authorization;
I may have to update the reverse proxy wiki to reflect this requirement, let's see if it helps.
with a publicly exposed API that I can call from a remote location using my API key.
Not sure if you've checked out the official API documentation, but it could help get you started. It includes all the endpoints with auto-generated code examples for each.
Anyways, let me know if adding the auth header helped!
from youtubedl-material.
Thanks @Tzahi12345, it was /etc/nginx/conf.d/ssl-params.inc
causing this. I have commented it out, since this is not open to public internet so I'm good without it.
Thanks again for support and for project, keep up the good work and stay safe out there :)
from youtubedl-material.
@Tzahi12345 thank you for the response! I think my issue may not be caused by those proxy headers. I've attached a screenshot here showing 1) how the page partially loads behind my reverse proxy and 2) my console when I load the page.
It seems that several of the requests go through just fine, and my basic authentication is indeed correctly passed there if I look into the headers. It appears that calls to the API are the ones returning 401 Unauthorized.
Do I need to set an API key first and somehow pass it through here? If it would be better to break this out into a separate issue, happy to do so as well.
When I load the page behind reverse proxy w/ basic auth:
from youtubedl-material.
Do I need to set an API key first and somehow pass it through here?
Nope! Not necessary, the public API key you generate in the settings is if you want to access the API outside of your network and without a browser.
It seems that several of the requests go through just fine, and my basic authentication is indeed correctly passed there if I look into the headers.
Could you paste the headers that are being sent? Maybe it's improperly formatted. I still think it might be a header issue, as the requests that were successful don't require one (all the GETs at the top of the console). The header should be Authorization: 4241b401-7236-493e-92b5-b72696b9d853
. That header is a constant, and tells the backend that it was sent from the UI. It's not the most secure way of doing auth, so I'll be exploring better ways of doing this.
If it would be better to break this out into a separate issue, happy to do so as well.
It would be easier to track this problem if it were a separate issue, but solving it here is fine too (it's at least semi-related).
from youtubedl-material.
If I have basic auth turned on, this is what one of the successful requests looks like in the console. An auth header is passed. The authentication that is passed is a base64 encryption of my basic auth username and password set in my reverse proxy.
GEThttps://ytdl.myurl.com/#/home
[HTTP/2 200 OK 15ms]
Request URL:https://ytdl.myurl.com/
Request Method:GET
Remote Address:<<REMOVED>>>>
Status Code:
200
Version:HTTP/2
Response Headers (355 B)
Raw Headers
HTTP/2 200 OK
server: nginx
date: Wed, 15 Apr 2020 21:12:47 GMT
x-powered-by: Express
access-control-allow-headers: Origin, X-Requested-With, Content-Type, Accept, Authorization
access-control-allow-origin: https://ytdl.myurl.com
strict-transport-security: max-age=31536000; preload
x-served-by: ytdl.myurl.com
X-Firefox-Spdy: h2
Request Headers (633 B)
Raw Headers
Host: ytdl.myurl.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:75.0) Gecko/20100101 Firefox/75.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://nginx.myurl.com/nginx/proxy
Authorization: Basic <<THIS PASSES BASE64 ENCODE OF THE BASIC AUTH USER:PASSWORD I SET IN MY REVERSE PROXY>>
Connection: keep-alive
Cookie: experimentation_subject_id=<<REMOVED>>
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0
If I have basic auth turned on, this is what one of the unsuccessful requests looks like. Browser console doesn't give me a table of the headers, just this error message tree. If there's more detailed info that would be helpful to share here, let me know and I'm happy to post.
Also as this appears to be related to API calls, I tested a couple of things. If I make a CURL request from a remote machine as follows with basic auth disabled, the command works perfectly:
curl -XPOST -H "Content-type: application/json" -H "Authorization: myapikey" -d '{"url": "https://www.youtube.com/watch?v=video"}' 'https://ytdl.mysite.com/api/tomp4'
But if I enable basic auth and run the same command again, I get an error returned:
<html>
<head><title>401 Authorization Required</title></head>
<body bgcolor="white">
<center><h1>401 Authorization Required</h1></center>
<hr><center>nginx</center>
</body>
</html>
It seems to me that enabling basic auth via my reverse proxy is interfering with all API calls, whether made externally or for calls made from within the webui.
from youtubedl-material.
It seems to me that enabling basic auth via my reverse proxy is interfering with all API calls, whether made externally or for calls made from within the webui.
I think that's 100% correct. A possible solution to this is making the API key be a parameter rather than using the Authorization header.
I'll put it up as a hotfix when I get the chance to implement and test that out.
Let me know if you manage a workaround, I'll keep you posted on any updates in this thread
from youtubedl-material.
The location block that I added to NGINX above seems to function as a workaround here.
This seems to keep my home URL protected by basic auth, and I can make calls to the API by passing my API key as an auth header. Attempts to access https://example.com/ytdl/api in the browser redirect to home and prompts for reverse proxy creds. Seems all good so far, I'm going to test browser plugins next.
I don't know if it's a big ask on time, but some applications offer the ability to put up a login form page to provide security without requiring setup of reverse proxy http auth and introducing the chance of that interfering with API auth. Would something like that be feasible here?
from youtubedl-material.
The location block that I added to NGINX above seems to function as a workaround here.
Weird, not sure why that is. I'll look into simplifying that page by just using the subpath location block for all configurations.
Would something like that be feasible here?
It's actually something I want to add in the next update, as part of a multi-user mode I want to develop. You could enable that mode, and just have one user protected by a password. It'll require changing a lot (every user would have their own set of videos, and maybe permissions), but it seems to have interest and would solve the auth problem above.
I don't want to take on too much responsibility security-wise, but the ability to have multiple users is too tempting, so I'll make sure to salt and hash the passwords appropriately to make it secure enough. Anyways, it'll be in the works for the next few weeks.
Feel free to open up an issue if anything else comes up, or if you just have a suggestion. They're always welcome.
EDIT: I've updated the latest
and 3.6
Docker images to pass the API key as a query param (so it appends apiKey=API_KEY
to the end of the URL). Here's the relevant commit. Should prevent anyone else running into the same issue, as the Authorization header stays untouched.
from youtubedl-material.
Related Issues (20)
- [BUG] Scheduling a task hangs application, won't start fully HOT 1
- [FEATURE] Make mounted folders paths configurable using environment variable
- [BUG]
- [BUG] Searching goes on forever HOT 2
- YoutubeDl material doesnt download a subscription. HOT 5
- [BUG] pm2 not declared as dependency
- [BUG] Skipping player responses from android clients HOT 1
- [BUG] Can't add subscriptions. It just loads forever and never adds the channel. HOT 2
- [BUG] container won't start HOT 9
- [BUG] Video file name too long error
- [BUG] Thumbnails don't load if their path contains a "%" character HOT 1
- I'm looking for the best way to set the codecs for downloads
- [BUG] Cant delete individual notifications
- [BUG] Should install mutagen when program installed (esp. for Docker)
- [FEATURE] Explain execa, delimiters, argument usage better & include some helpful messages when people enter custom args HOT 3
- [BUG] Memory leak while downloading a big playlist HOT 3
- [BUG] Shows plain HTML after upgrading to Traefik v3 HOT 3
- [BUG] ERR_INVALID_ARG_TYPE container won't run when providing uid/gid
- [BUG] NPM outbound internet http traffic failing to use system http_proxy variables (NOT NPM config related)
- YT bot alert since last night - How can I sign in with MFA? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from youtubedl-material.