I have a webpage that embeds a flash widget that sends AJAX POSTs. I use PHP to interpret these on the server.
The problem is that Internet Explorer doesn't send the "Cookie" HTTP header from the requests generated in the Flash, so I'm unable to pick up my PHP session on the server.
Chrome and FF do send the Cookie header from inside the flash.
I've tried the P3P headers and browser security settings changes.
Does anyone know if this is possible within IE? I can't change the flash, so would have to be a browser setting, or ideally, some HTTP change...
If its a problem with IE you can probably fix it for yourself by installing the newest version of IE and Flash on your computer. Other people are probably going to have trouble with it however. I really don't know what you are talking about with "Cookie" header but I don't see why that would stop you from handling a request if it is getting sent. If you wanted to post the code that is handling the request that would probably be helpful.
In reality, you probably shouldn't be using a Flash solution to handle your ajax requests.
Related
I would extremely appreciate some help with the following issue:
I have a payment web app hosted in IIS and configured for SSL. I need to integrate a POS terminal (or pin-pad) with a static IP that's not SSL compatible. I can talk to it running the site without SSL (HTTP to HTTP), but not HTTPS to HTTP - obviously getting "Mixed Content ..." error as Chrome doesn't allow that. I don't need to care about other browsers, but I can't run my site HTTP and as mentioned terminal doesn't support HTTPS.
Now, before you mark it as duplicate - I've read:
sending request from https to http from chrome extension,
Chrome extension - Disable Blocking of Mixed Content
Since v38, Chrome extension cannot load from HTTP URLs anymore, workaround?.
And it looks like Chrome extension might provide a solution. I don't have any experience with Chrome extensions though, but comfortable with JavaScript. I would prefer to avoid chasing something that would result in a dead-end. So, my question is - am I on the right path? If so, how do I go about implementing this? How do I go about delegating the ajax post call to the extension?
Any thoughts, ideas, tips, suggestions would be highly appreciated!
If you are going to use chrome-extension, do you want everyone who visits your payment site install the extension first? If the answer is yes, then sure, chrome-extension can help with that. Take at the following guide:
Cross-Origin XMLHttpRequest, it tells you that background page can send request to http site, even if current page is https
chrome.webRequest.onBeforeRequest, it tells you that you could redirect a http(s) request.
I've got an application that needs to support IE8 (with Google Chrome Frame), that will make cross-domain requests. I understand regular IE8 makes use of XDomainRequest for these calls, but when using Chrome Frame and looking through the console, I don't see XDomainRequest listed in the window object.
Since I'm using Chrome Frame, I understand I'm using the Chrome JavaScript engine... but does this mean I should be able to use XMLHTTPRequest for CORS? When I try that, I get a cross-domain error in the console.
Can someone clarify how this should be working? I'm confused.
IE 8 doesn't support CORS, but you can look into JSONP if you're only doing Get requests. There are however a few security concerns with JSONP though.
Another approach is doing a reverse proxy which means you create a page/service on your own domain that in turn makes the request to the other domain. This gets around the cross domain issue since the browser requests a resource on your domain.
I have a web app that makes cross-domain Ajax requests. The requests go through without a problem in almost every environment except for iOS devices (iPad, iPhone) running Safari 7. On those devices, the request fails. It works with the latest desktop Safari and also with mobile Safari 5; the problem is only with mobile Safari 7 (and perhaps 6; I don't have access to one of those for testing).
The app first makes a GET request to the origin site (with http protocol), which works fine. It then makes an https POST request to a different site (which is correctly configured for CORS). This is the request that fails. Nothing appears in the Safari console when the request fails and the server logs indicate that no request arrived.
One more detail that may or may not be relevant: the sequence of two requests is triggered by a single user action.
Does anyone have an idea of what's going on here?
EDIT The problem definitely appears to be related to Enyo. I created this fiddle that demonstrates the problem. If you are using Mobile Safari 7 and select enyo.Ajax as the tool for making the request, it will fail. The same request to the same URL will succeed using an XMLHttpRequest object directly. (The server-side script simply echoes the request headers. It also adds
Access-Control-Allow-Origin: *
to the response.)
Looks like this was related to a fix we made for iOS to prevent caching of non-cacheable requests. This fix was updated to only apply to iOS 6 in 2.3.0: https://github.com/enyojs/enyo/commit/73ade2a9dd68deb2f4a4db548c45e2c27104632f
Per the comments in the fix, you can use the header property to specify an object with cache-control: null, unless you're planning on upgrading to 2.3.0. :)
I ran this by the Enyo framework team. No one is exactly sure why you might be having the problem but it could be:
1) This: iOS 7 javascript XMLHttpRequest bug
2) A certificate issue with the https server.
It doesn't appear to be a framework issue, though. If the answer is something else, please let us know!
I'm trying to store a value on another domain using an iframe (actually, I'm using the xauth library at http://xauth.org/info/). However, when I try to store anything using Chrome, it comes back with "QUOTA_EXCEEDED_ERR: DOM Exception 22", which I've come to recognize as an access error. I've mocked up a couple of very simple pages below to duplicate the effect:
File 1.html:
<html>
<head/>
<iframe src='http://127.0.0.1/2.html' />
</html>
File 2.html:
<html>
<head/>
<script>
console.log(localStorage);
localStorage.setItem('test', '123');
</script>
</html>
If I place both of these on my local server and access localhost/1.html it embeds a frame from 127.0.0.1 (which Chrome considers a separate domain), and I get the same access error as above. At a guess, it looks like even though I'm embedding an iframe from another domain, and the script inside that iframe references the localStorage for that domain properly (as I can see with the console.log(localStorage) line), the permissions for writing to localStorage are coming from the top page's domain.
In short, it looks like no iframe can write to localStorage in Chrome. Does anybody know if there's a way around this particular security "feature"? Or am I doing something wrong?
The problem only occurs when third-party cookies are disabled. Newer versions of Firefox and Opera are also blocking it. In IE and Edge it is still possible although third-party cookies are disabled. If the localStorage would not be blocked in the iframe, a web tracker could simply include a iframe, read the cookie, send it to the parent script, and then send it to the server.
The reason why this is not blocked in IE and Edge is that these browser allow websites to send third-party cookies, which were previously set as first-party cookies, to the server although third-party cookies are blocked. For example, if a user visits facebook on a regular basis, he gets first-party cookies from facebook. When he then visits other websites with facebook's share button, facebook can track him although third-party cookies are disabled. I really do not know why IE and Edge do not block third-party cookie sending, but I would not use these browsers anyway.
The errors the browsers show when third-party cookies are disabled:
Chrome and Opera: Uncaught DOMException: Failed to read the 'localStorage' property from 'Window': Access is denied for this document.
Firefox: SecurityError: The operation is insecure.
IE and Edge: No error, access to localStorage in iframe is possible although third-party cookies are disabled.
So in conclusion, it is not possible to bypass this security feature (in Chrome, Firefox, Opera) and this is good in order to ensure users' privacy.
This is an old post, but if someone else see it- you can use postMessage
https://stackoverflow.com/a/40469196/4836581
Well, localStorage is domain-based and there is no reason for your example code to fail. What it actually does is to set the test item to 123 for 127.0.0.1 whereas it will leave the localhost localStorage empty.
This might not be the answer to your initial problem of QUOTA_EXCEEDED_ERR, but just try to switch to private browsing on Chrome (Ctrl+Shift+N) to see if you still have the error. Without further information on what you were initially doing, I can't tell much but I believe that quota exceeded means what it means...
And I think Chrome's quota is 2.5mb unlike FF which has 5mb of localStorage quota.
I'm a bit confused about how you can or cannot make crossdomain ajax requests in addons for Firefox. Addons such as LastPass and Xmarks suggest you can do it, however when I try to google how you do it, everyone seem to say you cannot, unless the user has set a preference in the settings of Firefox. If crossdomain isn't possible, then how do Xmarks, LastPass and other addons handle the communication with theirs respective servers?
You most definitely can make cross-domain XMLHttpRequests in Firefox add-ons.
There's a reference to it here: https://developer.mozilla.org/en/Extension_Frequently_Asked_Questions#I_cannot_initiate_an_XMLHttpRequest_from_my_extension