First of all thank you for such good project. I'm using it in docker and everythin

<a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/us

Thanks <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-u

<a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/us

HTML not rendering when behind nginx about youtubedl-material HOT 12 CLOSED

tzahi12345 commented on July 24, 2024

HTML not rendering when behind nginx

from youtubedl-material.

Comments (12)

Tzahi12345 commented on July 24, 2024 1

@nebula-it Thank you! Feel free to open up another issue if anything else crops up.

from youtubedl-material.

crosbyh commented on July 24, 2024 1

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.

Tzahi12345 commented on July 24, 2024

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.

crosbyh commented on July 24, 2024

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.

Tzahi12345 commented on July 24, 2024

@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.

nebula-it commented on July 24, 2024

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.

crosbyh commented on July 24, 2024

@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.

Tzahi12345 commented on July 24, 2024

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.

crosbyh commented on July 24, 2024

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.

Tzahi12345 commented on July 24, 2024

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.

crosbyh commented on July 24, 2024

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.

Tzahi12345 commented on July 24, 2024

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.

HTML not rendering when behind nginx about youtubedl-material HOT 12 CLOSED

Comments (12)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent