1

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.

Asciiom
  • 9,867
  • 7
  • 38
  • 57
  • I've had this problem as well with Safari Extensions in 6. Haven't managed to get round it yet. – Alfo Feb 28 '13 at 17:49
  • Seems like a bug in Safari I think, and if that is the case it might be quite impossible to work around this... – Asciiom Feb 28 '13 at 17:57

1 Answers1

1

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.)

Andrew Magruder
  • 11
  • 1
  • The entire application runs in the iframe, the call from which the session id is stored in the backend model too. So I'd think all these calls are the same session. 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. – Asciiom Feb 28 '13 at 18:10
  • If it really was their policy causing this I should get that behaviour regardless of wether I opened the application in a separate tab once. – Asciiom Feb 28 '13 at 18:14
  • Safari is being smarter about detecting what's going on than you're giving it credit for. :) Here's another Stack Exchange answer with a PHP workaround: http://stackoverflow.com/questions/9930671/safari-3rd-party-cookie-iframe-trick-no-longer-working – Andrew Magruder Mar 01 '13 at 14:39