Open TimoVerbrugghe opened 7 years ago
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...
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.
Yeah apologies, still happening on the latest version of Chrome (60.0.3112.101). If you need more info, just ask ;).
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 .
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)
EDIT: Just added this site to muximux hosted on my server, get the same chrome error, so I think you have your testing subject
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...
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 ;).
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.
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 ;).