I'm using jQuery's ajax .get method to retrieve data from my server. Works perfect in Chrome, but in IE9 it is not sending the Cookie header and that breaks the app. Any idea why? Here's the jQuery code:
$.get(this.server + 'rest/photo/' + this.profileId + '/count', function(data) {
$('#imageCount').html(data);
});
I have the same problem here, I can't get the jQuery .ajax() function to work. The only workaround I found is this:
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8" />
You can add this meta tag to the top of the page to get it working. But it doesn't feel like a good solution. I think the problem is that the xmlhttprequest object in IE9 is different, so jQuery cannot find the respective object, therefore ajax is not triggering.
I ran into a similar issue to the OP many years later with IE9 which, sadly, is still hanging on.
Every browser I tried, including IE10+, seemed fine with passing cookies to my backend, but IE9 would just drop them. It didn't seem to matter what attributes were on the cookies. The main page and API were on the same domains and the cookies matched, the schemes were the same. I wasn't doing anything with IFRAMES, so the P3P 'potato' hack didn't help.
So I started doing some research on what it was about IE9 that could be different. This Microsoft post was very enlightening, and outlines all the things the IE8 and IE9 did to help lock down CORS security holes:
Must use HTTP(S), and both endpoints must use the same scheme
Must use GET/POST
No custom headers allowed
Only text/plain content-type allowed
More sensitive to Security Zone settings
Cookies will be stripped from the request
That last item about the cookies got me thinking, what if IE9 thought I was making a cross-site request? It certainly looked like it was getting shot down in fine fashion like that. I had already checked some of the obvious things like the scheme and domain, but maybe I didn't check everything.
The solution? Specifically, I was using reqwest as my ajax library. It has a cross-origin parameter, which I had left set to true for some reason. Setting it (correctly) to false did the trick - all my cookies were picked up by the server. So it was a dumb mistake, but I learned a thing or two.
Hope this helps someone!
Related
A cookie has been set with the SameSite=Strict attribute. When Javascript tries to read the cookie before making an XHR request the cookie seem to be unavailable. But the developer tools show the cookie exists. This problem is happening only in the recent version of Firefox. Not sure if I am missing anything. The domain and the path are set right on the cookie.
Apparently, it depends on how you get to the page that performs the XHR request. If you get there by clicking on a link on another website (say, following a link on your webmail client), the Strict cookies will not be available, even in subsequent XHR requests! This behaviour seems to be different in Firefox than in other browsers.
Some more info you may find here: https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/
I still don't know why, I think it about the firefox behavior, I fixed by using location.replace("") to reload page, but you can also use "lax" or "none" to fix that.
My web app runs under Tomcat, it uses AJAX requests very intensively, and during the development process I have to redeploy the web app intensively too. After the redeployment I usually simply refresh the page knowing that the user session is dropped, but I always get to the scenario described below:
Go to some page, a really big page with many JS-scripts included, that actually makes those intensive AJAX requests.
Stop Tomcat or redeploy the web app.
Refresh the page.
Enter the credentials in the sign-in form to authenticate.
Suddenly get the last AJAX request response in the browser window and the AJAX request URL in the URL bar.
Wow... It looks strange for me that AJAX request URLs appear in the URL bar along with their response in the web page display area. This actually happens to Firefox and Chrome (haven't tested it in other browsers). Unfortunately, I cannot reproduce the same behavior in a simple page written from scratch. Frankly speaking, I don't really understand what happens to such requests and why do browsers "think" if AJAX requests/responses are entered in URL bar by user...
Your possible explanations or hints for such a strange behavior are very and very appreciated. Thanks!
(Perhaps it can help: All AJAX requests are performed with jQuery 1.4.2)
I'm very sorry, as I understood later, the question is not complete, because there was another pitfall I didn't mention, so no one couldn't answer the question in principle. The reason of the bug was hiding in the... <body onunload="..."> tag definition. That was quite unexpected, but that code contained some AJAX request that must be invoked when a user leaves the page. I only realized that the authenicating module (FORM, j_security_check) returned a response (HTTP 302) containing the Location header - so that was the reason why browsers did redirects.
The exact scenario was like that:
Open the page containing <body onunload="some_ajax_here">.
Log out the app using another tab so you could stay at the same page.
Refresh the page so some ajax could be invoked - this AJAX request is not now allowed because it's a secured part of the application (you get the forwarded content of the login page).
Enter the credentials and now oops you get to the result of some ajax directly in the browser window.
As the quick fix, and I hope the final one, I added another request following that AJAX request:
$.ajax({
async: true,
method: "GET",
url: document.location.pathname + document.location.search
});
So the HTML page script simply makes self-page request the last one - j_security_check returns the Location referring the last used HTML page, and the redirect works fine. Perhaps my explanation is not clear and may be not complete or even full of mistakes, but it looks like that in general. I'm very sorry once again, and thank you #ChristopherSchultz!
I am experiencing random occurrences of caching of Ajax requests created through Jquery's get.
The Jquery gets are done in the most straight forward conventional way (route + params + callback)
I am already using
$.ajaxSetup({cache:false});
But it doesn't seem to always work. I get how ajaxSetup no cache works, and I see the added random parameter being added to my request url.
My current browser is IE 8.0
Does anyone know of another solution besides the ajaxSetup way...
The browser itself is simply not allowed/able to cache requests with distinct parameters, as added by {cache:false}.
It sounds like the caching is happening somewhere else in your chain, possibly in your web server/app.
Use firebug's net tab to check exactly what is being requested by the browser, and what the URLs are exactly, then take it from there.
It turns out I was wrong about my assumption about caching of ajax requests.
The real issue was caching of subsequent redirect to action requests that took place on the server (in response to the original ajax call).
The solution ended up being the following attribute.
[OutputCache(Location = OutputCacheLocation.None)]
It can be either applied at the controller level or the action level.
I have the same issue as is explained here, in short:
I am using an iframe to post files to the server AJAX-style, then receiving a JSON response to tell me if the file was uploaded and parsed successfully. This works great is every browser except IE9. Instead, IE9 prompts me to save or open the JSON, and will not pass it back to the iframe.
In the other SO question for this, EricLaw -MSFT suggested to set the content type to "application/json", which I have done, but to no avail.
Does anyone know how to get IE9 to let the iframe have its JSON?
Well it looks like setting content type to "text/html" does the trick. It's less than ideal since it's not descriptive of the content, but oh well. Hope this helps someone else too.
HTML Forms are limited to sending data in three different content types: text/plain, application/x-www-form-urlencoded, and multipart/form-data
To workaround this issue, server code that currently processes HTML Forms must be rewritten to manually parse the request body into name-value pairs when receiving requests from XDomainRequest objects. This makes adding support for the XDomainRequest object more difficult than it would be otherwise.
References
XDomainRequest - Restrictions, Limitations and Workarounds
HTML Living Standard: Association of controls and forms - The enctype and formenctype content attributes
I would be grateful to find out some really weird things I have seen on facebook URLs
If I bookmark this URL (found when JS is enabled)
http://www.facebook.com/HumanRightsWatch?v=app_2344061033#!/HumanRightsWatch?v=box_3
Then disable JS
I then proceed to revisit the same url
e.g. http://www.facebook.com/HumanRightsWatch?v=app_2344061033#!/HumanRightsWatch?v=box_3
and its sends me here:
http://www.facebook.com/HumanRightsWatch?v=app_2344061033&_fb_noscript=1
There is no redirection happening, im checking headers and getting a 200 ok
My question is, how is this done? I guess it cant be using JS redirection because thats disabled. Is there any other form of redirection that it could be using without showing it in the headers?
Yours, deeply confused :#
Cheers
Ke
ahh i see, its using a meta refresh tag