Closed predakanga closed 7 years ago
Ah, it's already been marked as a regression: https://bugs.chromium.org/p/chromium/issues/detail?id=707761
Might still be nice to use [null, null] for the username and password though - according to the MDN that's the standard behaviour.
EDIT: I was asked to split that discussion to a separate issue - https://bugs.chromium.org/p/chromium/issues/detail?id=708131
Awesome catch and workaround, will try to get this out ASAP.
On Tue, Apr 4, 2017, 7:43 PM predakanga notifications@github.com wrote:
Ah, it's already been marked as a regression: https://bugs.chromium.org/p/chromium/issues/detail?id=707761
Might still be nice to use [null, null] for the username and password though - according to the MDN https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/open that's the standard behaviour.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/khloke/play-to-xbmc-chrome/issues/112#issuecomment-291448971, or mute the thread https://github.com/notifications/unsubscribe-auth/ACnwNwK4MsZFNr8Joj4ESMzLQNm-6vLJks5rshDOgaJpZM4Mym3y .
There's also a workaround for users that do need authentication at https://bugs.chromium.org/p/chromium/issues/detail?id=707761#c8
Also, a remote control extension works fine. Shouldn't that also not be working?
PS I am not using uid/pwd
I'd be curious to see what extension that is; could you provide a link?
On Sat, 8 Apr 2017 at 4:53 pm, cffm notifications@github.com wrote:
Also, a remote control extension works fine. Shouldn't that also not be working?
PS I am not using uid/pwd
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/khloke/play-to-xbmc-chrome/issues/112#issuecomment-292699625, or mute the thread https://github.com/notifications/unsubscribe-auth/AAysteSiUdLy8UhyfjLn0TfmFfS1L7Rxks5rty7igaJpZM4Mym3y .
-- Lachlan
Sure, using it as we speak and works fine
That app does however not have the feature to share a URL. It may use a different way to talk to Kodi...
Yep, I just had a look at how Kassi works - it uses the same API, but over WebSocket instead of HTTP.
If username/password support does get removed from Chrome this would be a viable solution, but I don't think it supports setting a username/password.
Never understood password anyway. I mean, who do you need to prevent from pausing a video so bad that it needs to be password protected? You most likely live with that person.
Therefore, it would be great if the uid/pwd is left blank, it would simply not try to send uid/pwd? Would that work? Or does it have to be sent as blank and qualifies for Google to trigger the error?
So, since Google won't change, is it safe to assume this add-on is now dead?
I will fix it so you can still use it without username and password. The workaround @predakanga mentioned seems to work, so I'll try that. I'll do something in the next few days, maybe you guys can test it out for me.
Nope, Google has actually changed their mind on this, thankfully!
As described in https://bugs.chromium.org/p/chromium/issues/detail?id=707761#c31, they're allowing credentials to be used in XHR going forward - the changes have already landed in Chrome Canary.
That issue isn't closed yet so I suppose they could change their mind again, but unless that happens we should be able to consider this issue fixed :)
I am using Canary. I will let you know when it starts to work.
Thank you!
Running Canary 60.0.3076.0 built 4/20 and it works! Awesome fix that I guess required zero work ;)
Symptom
In Google Chrome Canary (version 59.0.3059.0, 64-bit, OS X), trying to play a video has no effect; opening the extension pop-up shows the message "Unable to connect to Kodi".
Cause
Chrome is phasing out support for sending credentials in the URL - viewing the extension's console messages shows the following warning:
[Deprecation] Subresource requests whose URLs contain embedded credentials (e.g. `https://user:pass@host/`) are blocked. See https://www.chromestatus.com/feature/5669008342777856 for more details.
I know that this extension isn't directly doing this, but it seems that you're getting caught up in the change anyway. This results in all your calls to ajaxPost being blocked with an origin error:Workaround
I've found a workaround for a specific case - if the user isn't using authentication, getCredentials() currently returns ["anonymous",""]. Changing this to return [null,null] allows the request to be sent and the extension to function as normal.