Subresource requests whose URLs contain embedded credentials are blocked

[TimoVerbrugghe]

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: https://github.com/Rudloff/alltube/commit/480271a45e7d7b8801eb8cc48e39ea3b871d7ef4

Hope you can do something with this information ;).

[d8ahazard]

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

[TimoVerbrugghe]

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.

[TimoVerbrugghe]

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

[d8ahazard]

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 notifications@github.com 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 https://github.com/mescon/Muximux/issues/155#issuecomment-323338023, or mute the thread https://github.com/notifications/unsubscribe-auth/ABjuNKYcLJKQ_dCbdkVnZmUd47MCA9Zxks5sZYCHgaJpZM4OPxGC .

[TimoVerbrugghe]

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

[d8ahazard]

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

[TimoVerbrugghe]

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 ;).

[TimoVerbrugghe]

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.