17

We have a web app that runs in Facebook (i.e. a running in an iFrame at a different domain). If a Safari user has Cookies and Website Data set to the default, "Allow from websites I visit", the data we store via localStorage.setItem is acting like sessionStorage, i.e. it's not available beyond the user's current session (i.e. after the user closes the tab). If we change the setting to "Always allow", it works fine just like in Chrome, IE , etc.

As a test, we've tried navigating the browser to our app's domain (https://ourappname.appspot.com) directly and it works fine there. And also then it should truly be a visited website, but when going back to the game within Facebook, the problem still exists.

Note that the setItem call is succeeding, it's just that getItem doesn't return anything in a subsequent session. (So it's not like when the user is Private Browsing and the setItem call itself fails with a Quota Exceeded error.)

What do we need to do to support Safari so that our app, running within Facebook, can use localStorage as intended where the data will survive between sessions?

leontx
  • 1,165
  • 1
  • 14
  • 24
  • Weird, I just tested in Safari 8.0.7 (10600.7.12) with "Allow from websites I visit". I set a localStorage key and then closed the browser (with ⌘+Q) and when I reopened the browser and used localStorage.getItem it was there. – daviddoran Jul 14 '15 at 07:08
  • @daviddoran thanks. Were you testing a site running in an iFrame that was a different domain than the top level site? I'll edit my question to make that more clear. – leontx Jul 14 '15 at 08:07

2 Answers2

9

It's either a bug in Safari or a security feature.

You are visiting FaceBook and not your website. Your app is in iframe which would violate security model if it let you read any data from the browser. Think if a competitor site read data it did/didn't set. That'd constitute an information leak.

Safari is doing it's job well in that regard.

Ideally, in "Allow from websites I visit" mode, no browser should let iframes to set data to localStorage; even if every domain has their own storage-sandboxes.

What's troubling me is why are they even letting you write to localStorage from iframe at all (in your 'Allow for only sites I visit' mode)? That might actually be a bug - a information spoof attack enabling bug.

I think it's because security-exceptions were dropped from localStorage in case of not-same-party origin of request. So Safari might actually will not throw error but let it silently fail (in some cases). That's probably why your setItem call is succeeding.

At this point, with the given information, I suspect, sir you are out of luck due to Safari programmers following standard to the letter.

  • thanks for the thoughtful answer. It does seem that if a user has navigated to our site directly, then our site would be enabled to read/write localStorage. That part also seems like it could be a bug? And my main question as to what we need to do... let me know if you know of any workaround. I'd think most Facebook canvas apps must have found some workaround to this issue? – leontx Aug 04 '15 at 01:12
3

I'm still waiting on a reply from Apple, but it's safe to say we're stuck with this behavior. So Anubhav's answer is accurate, but we still needed a solution.

So as a work around, we created new endpoints on our server for persisting/restoring game state. We only utilize this for Safari, for all other browsers we're still persisting our game state in localStorage.

There is a slight performance penalty for the user. And a slight server cost. Not a sexy solution, but now our Facebook canvas app supports Safari.

leontx
  • 1,165
  • 1
  • 14
  • 24
  • Did you ever hear back on this? I've run into this issue too. My scenario is very very similar (iFrame, etc). – Wesley Workman Dec 21 '15 at 15:26
  • 2
    @WesleyWorkman No new information since posting this answer and my comments. This was our workaround, and has been in production for a few months and working okay. – leontx Jan 06 '16 at 22:30