Subresource requests whose URLs contain embedded credentials are blocked

Question

Subresource requests whose URLs contain embedded credentials are blocked

TimoVerbrugghe opened this issue 7 years ago · 8 comments

It seems that Chrome recently started blocking websites that requests other pages in a frame using embedded credentials, which muximux does when you add username & password through the settings page. See https://www.chromestatus.com/feature/5669008342777856.

Am not a coder myself, but it seems that Alltube (which is also written mostly in PHP) recently had the same problem and this commit solved it: Rudloff/alltube@480271a

Hope you can do something with this information ;).

Answer 1 · 2017-08-17T21:11:46.000Z

Just took a look at the fix they did - basically, they're just firing plain-jane HTTP requests to a URL using the GuzzleHTTP library.

In English - they're actually talking to the webpage. We're just taking the URL you give and loading it in a frame. In order to pull this off, we'd have to actually cache the entire page to be loaded.

Not impossible, but it would require a fundamental reworking of how Muximux behaves...

Lemme think on this one...

Answer 2 · 2017-08-17T22:08:12.000Z

Hi d8ahazard,

I'll test some more, I remember filing this bug some time ago, but I used muximux yesterday and I could access all my pages (even password protected ones).

Will confirm tomorrow.

Answer 3 · 2017-08-18T12:16:06.000Z

Yeah apologies, still happening on the latest version of Chrome (60.0.3112.101). If you need more info, just ask ;).

Answer 4 · 2017-08-18T12:21:19.000Z

Is the credentialed page you're trying to access something I can get/try on my own machine to see if I can replicate it and come up with a workaround? I was playing with phpProxy last night, it could possibly be incorporated for pages that can't be loaded in an iFrame...

…

On Fri, Aug 18, 2017 at 7:16 AM, Timo Verbrugghe ***@***.***> wrote: Yeah apologies, still happening on the latest version of Chrome (60.0.3112.101). If you need more info, just ask ;). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#155 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABjuNKYcLJKQ_dCbdkVnZmUd47MCA9Zxks5sZYCHgaJpZM4OPxGC> .

Answer 5 · 2017-08-18T17:59:15.000Z

Yeah sure!

I made up a test folder on my server, with just an index.html file in it.

Password protected with username "test" and password "test" using Apache's AuthType basic (the same I use for the other pages on my server)

https://www.timo.be/test/

EDIT: Just added this site to muximux hosted on my server, get the same chrome error, so I think you have your testing subject

Answer 6 · 2017-08-22T22:33:32.000Z

Okay, I've tested as well, I see what you mean. That blows. According to my findings, it is a bug with Chrome, but their possible way of fixing it might be to remove the functionality altogether.

I can see if it's possible to somehow post the data using js, then populating the iframe with the response, but that's hacky and not super-ideal.

Curious - can't you use some kind of credential storage on the site in question to make it so you've only got to authorize once in a while? Not a fix, but just what I'm used to dealing with in couchpotato, sonarr, etc...

Answer 7 · 2017-08-23T21:13:46.000Z

Is it really a bug in chrome? Seems more like a security feature with me :p. Mmm, I don't know if apache supports something like that, I'll check ;).

Answer 8 · 2017-08-26T22:14:53.000Z

Allright, issue could be solved by using Apache's mod_auth_form module, which allows you to set up a custom html page for signup (instead of Apache using the browser's built-in sign in form).

Problem is that in my specific case, I cannot use this since I also use android apps (transdrone, nzb360) that relay on username & password in the url to authenticate with f.e. sonarr/radarr/nzbget.