This is breaking quite a bit of our stuff and fixes... nothing. Unless you count getting players windows username a major security issue(wot.)
Please please revert this change and go back to the file URIs.
ID:2215636
 Feb 19 2017, 9:40 pm
|
|||||||
Redundant
| |||||||
|
Feb 19 2017, 10:09 pm
|
|
Lummox JR
  |
What is breaking? If you have some examples of things that aren't working I'd like to fix them.
|
A cross-origin ajax request from a browser control that used to work, no longer does (permission denied error), that I'm told is a result of this change. So there's an example I guess.
| |
If you can get me some example code on that I'll be happy to take a look. There's likely something I can figure out there.
| |
Its literally an AJAX request to another domain. It allows us to prevent having extrenuous communication with the BYOND server by cutting it out as a middleman and communicate directly with a website.
While we can add CORS headers to our website, IE is very bad when it comes to listening to these and just tends to explode and give up, something that didn't occur with file:// URIs(which is also against the standard but microsoft) | |
A snippet:
var xmlHttp = new XMLHttpRequest(); The open() request now fails with the permission denied error. | |
I'll take a look into this.
| |
I ran quite a few tests on this, and I was unable to reproduce your results. open() did not give me a permission denied error under any circumstances, and if I gave the request an onerror() handler it fired only in cases where I expected it to: cross-origin requests when the required Access-Control-Allow-Origin header wasn't present.
Tested: - Request to Google for the jQuery library (always passed) - Request to byond.com main page (always failed) - Request to localhost:port for a file (always passed) - Request to [local IP]:port for a file (passed if opened to CORS) - Request to [external IP]:port for a file (passed if opened to CORS and port forwarded) So the question I have first of all is: does your website have the required CORS headers? If not, I think that's the problem, because this worked swimmingly for me. Worth noting: I was also using the X-UA-Compatible header and html DOCTYPE. | |
Odd. The resource has the CORS header and the browser has similar meta/doctype tags. I guess more tests are needed.
| |
One important question: Are these results being seen universally, or only by certain users?
If you can distill this down to a test case, that will help too. I was working in the dark trying to reproduce your issue from scratch; it's possible there's some factor in your code that isn't in mine that does cause a problem. BTW I was testing in release mode 511.1374 except for the latter two CORS cases which were done in the debug build. | |
This is pretty much an issue for everyone of our people that use popups that do this. We're all using IE11 (on windows 10.) We did have a window.onerror handler so you might not be catching all the errors. We have all the necessary CORS headers (and then some just for verification). I'll be sending you a URL you can test against though.
| |
What does the actual HTML/JS of the caller look like?
| |
Pretty much exactly what was posted above but with an additional header set (which is allowed in the CORS headers.)
Best part is that once IE sees the lack of CORS headers (which didn't exist when we first noticed the issue because we never needed them before), there seems to be no way to clear its memory of them not existing, despite clearing of history and cache. So we're at an impasse, it seems. | |
That's odd, because I tested with and without CORS headers for the last ones and it didn't have any kind of "memory" for those.
Have you considered setting a Cache-Control header at the server end to kill any caching whatsoever? I should note that in my tests I was using no-store, no-cache, must-revalidate, and max-age=0, so maybe that made a difference. | |
I was monitoring the request logs and got no request whatsoever -- including the CORS OPTIONS request -- after its made once. The moral of the story appears to be that IE is incredibly inconsistent and loves making developers' lives hell :V. I can't really go forth with testing unless I can find a way to make IE re-send an OPTIONS request.
| |
I found this topic on the subject, but the person who asked about it found that the preflight cache wasn't the problem after all; clearing the browser cache actually did, as it turned out, work for him.
I wonder if it's something else here. Are you getting an "Access denied" on the open() call itself? Because I definitely have not been. | |
Another useful thread here had a problem on an obviously non-CORS request and solved it by putting the AJAX request on another thread via setTimeout().
Also: Are you certain you cleared the right cache? There may be a separate IE11 cache you need to clear, so if you cleared it from Edge that might not do it. | |
Yeah its on .open itself -- and yeah it was from IE. I'll keep playing with it now that its a new day though.
| |
Nothing I do will make it resend the request. At this point I'm not even certain it everm ade the request to begin with and instead just abroked because of the intranet zone being isolated.
| |
The page displays in the Internet zone. Unless you mean the URL it's querying is in the Intranet zone, but I very much doubt that's the case.
What happens if you try that setTimeout() workaround mentioned in the link above? And are you able to get me a full example HTML file using your exact code? That ought to help a lot for my tests, to see if there's anything different about it. | |