Reputation: 9975
Situation:
I have a Javascript/jQuery web app which communicates with a PHP/MySQL/Zend Framework 1.12 backend. The web app runs inside an iFrame (loaded with jQuery fancybox in iframe mode).
The application creates an object on the backend and saves the current session ID with it. It then displays the object's properties on the front end and modifies the object on the backend through ajax calls when the user interacts with the application. The session ID is used to check if ajax requests are coming from the same user (user is not logged in so it's the only way to check).
I use jQuery to do the ajax calls and Zend_Session to work with sessions in PHP/Zend.
Problem:
Now, the problem is that in safari 6, these ajax requests have a different session ID so they don't match the session id stored in the backend model object and access is denied.
This does only happen when running in an iframe, not on any other browsers, not on other versions of safari (5 or below)
Does anyone have an idea what can cause this and how to deal with it?
Some more info:
The entire application runs in the iframe, the call from which the session id is stored in the backend model as well. So I'd think all these calls have the same session id.
Another thing: once I run the application in a separate tab, and then in the iframe again, the issue disappears: from then on until I kill the browser session I get the same session id every time as I would expect. That smells like a bug to me, frankly.
Upvotes: 1
Views: 1527
Reputation: 11
The key issue is the iFrame. As a part of the Safari security model, requests running in iFrames are treated separately from the rest of the page requests. It's part of their 3rd party cookie protections. As I understand it, Firefox22 is going to start doing the same sort of thing, but not quite as restrictively.
If you're sure you really want to get around this, pull PHP's Session Id cookie out and put it on the query string for the request to the iFrame. You can then pull the session id from the query string and use that one. (You won't end up with one in the cookie data if you do this.)
Upvotes: 1