My project was previously on openfl 3.5.1 and lime 2.8.2. I bumped these versions to the latest, openfl 3.6.0 and lime 2.9.0.
Immediately after the versions changed all load requests get a 401 (Authentication Required) error and none of my image assets are showing up in game. I am playing my project from https:// path and have ldap auth. They do still properly load from normal http (unsecured) urls.
I did a diff of the two openfl versions and it does look like some changes to various loaders and classes in the net package, but I don’t know why the changes would have caused this behavior. Thanks for any assistance here!
I’m testing a build with this change rolled back. Will update the thread in a bit.
I admit to being a little confused, though: I thought .crossOrigin only applied if the origin differed, and it shouldn’t, in this case; the html, css, javascript, and images all reside in the same path under the same domain. But maybe it turns on CORS – https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_settings_attributes seems to suggest that this may be the case, indirectly, by saying “CORS is not used at all” when this is unspecified.
Commenting those two .crossOrigin lines out does seem to have fixed the problem.
With the .crossOrigin lines still present, taking care to force-reload each time (all on Windows 7 64-bit, since that’s where I’m sitting at the moment):
Firefox 45.0b6 (beta channel) does not exhibit the issue (good);
but Chrome 48.0.2564.109 m does exhibit the issue (bad);
Chrome 50.0.2653.0 canary (64-bit) is good;
Internet Explorer 11.0.9600.18163 is bad.
Will go hunt in the chrome bug database and changelogs.
I’m going to look into workarounds, see if we can apply .crossOrigin if and only if it’d be a cross-origin request in the first place. This sounds messy, not terribly hopeful, but seems worth a glance.
I’m at a bit of a loss. We could attempt retrying without the .crossorigin in onerror in lime.graphics.Image, I guess? But I’d prefer something along the lines of “if it’s the same origin, never set .crossOrigin in the first place”. Just not sure how to do the "are we same-origin" in a way that is as robust as the browser – indeed, even determining current script’s origin seems painful and error-prone.
I’m guessing most things developed using OpenFL+Lime will be deployed in a situation where .crossorigin="anonymous" as dictated by the earlier HTML5 standard (i.e. “omit credentials”) is a fine decision. So maybe extra overhead in our rarer case is reasonable. I’d love to know a little more about the cause for the original commit and the rationale behind the fix – probably a static CDN style situation?
Do you think it would help to cache window.location.hostname somewhere, and use a fast compare to try and guess whether we think it is local? If it is, then we omit the parameter, or we use the .crossOrigin attribute to try and help cross-origin requests?
Do you think it would help to cache window.location.hostname somewhere, and use a fast compare to try and guess whether we think it is local? […]
It would resolve our specific usecase. We’d be mimicking a part of the same-origin policy and there seem to be some subtleties to getting this right – see e.g. document.domain, and I ran across a handful of bug reports on the various browsers.
Trying to think about this a bit. False negatives are probably fine (saying “not same-origin” when in fact we are); false positives might be detrimental (if we only check hostname and not port etc, we might get some of these), but as long as it’s just used to drop .crossorigin, it might not be terribly harmful? There’s some possibility of running into a situation like that described in https://stackoverflow.com/questions/33586139/prevent-http-basic-authentication-from-displaying-prompt-for-images , though, without .crossorigin. Admittedly that’s mostly a problem for sites that host user-generated links, which is probably not what OpenFL is used for in most cases, but … I don’t like making assumptions like that. The onerror retry suggestion I made has this same possible flaw.
Still would like to know what the original commit was trying to address, specifically, so we don’t break that.
The conservative route might just be to wait for the browsers to move to the WHATWG standard version, but that might be a while.
May wire something up along the lines of what you suggested here today or tomorrow, just to see if it works. I’ll also try to also look a little more into the same-origin policy and see if there’s any way to evaluate that directly or indirectly.
