2

In our application we have some elements that work with ajax. We offer users to embed parts of the app in an iframe.

Everything work fine in Chrome and Mozilla. In Safari we get 422 error, and the server log looks like this:

2015-07-15T08:26:06.818885+00:00 app[web.1]: Completed 422 Unprocessable Entity in 4ms
2015-07-15T08:26:06.815411+00:00 app[web.1]: Can't verify CSRF token authenticity
2015-07-15T08:26:06.823389+00:00 app[web.1]: ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken):

We figured out that if we access directly the iframe url AND THEN to the page which contains the iframe it works fine, which might indicates that it has to do with cookies.

I tried this solution, but we still have this problem.

Community
  • 1
  • 1
guyaloni
  • 4,972
  • 5
  • 52
  • 92
  • 1
    The CSRF token check will fail if the session cookie is not set. This cookie—indeed any cookie—is not kept by Safari unless you access the url directly first, as you have found. – djb Jul 15 '15 at 18:04
  • I don't understand what you and @djb mean by "access directly". Are you manipulating the DOM? Loading the iframe? – Tyler Collier Jul 21 '15 at 19:04
  • 1
    I saw your comment [here](http://stackoverflow.com/questions/21033364/why-is-safari-causing-a-rails-csrf-exception-where-chrome-isnt#comment50808589_21040330) and it makes sense now: "you either have to work without cookies, or bring the user to your website and set a cookie there" – Tyler Collier Jul 21 '15 at 19:15

2 Answers2

1

Safari does not (by default) allow cookies to be set in iFrames unless the user has visited the site already. Imagine this code:

# a.com
<iframe src="b.com/iframe">

If you visit b.com directly (any page) and it sets a cookie, then Safari will send that cookie when you visit a.com and the iFrame to b.com is loaded.

However, if you visit a.com without first visiting b.com, then Safari will ignore any cookie that b.com/iframe tries to set.

The solution is described here (if the link doesn't work for you, here is version saved by web archive) in the section called "A solution for Safari".

  1. Detect if cookies are supported.
  2. If not, put an overlay on the page saying, "This site requires cookies. Please click here to continue."
  3. When the user clicks on the link/button, open a popup, which sets a cookie and closes itself. On desktops you can make the popup fairly small and innocuous. On mobile devices it is uglier since you can't make the popup smaller than full-screen. However, either way the popup is only on screen for less than a second.
  4. The iframe reloads itself and it can now use cookies.
Kirk Hammett
  • 656
  • 8
  • 24
phylae
  • 973
  • 1
  • 10
  • 18
0

Finally I figured out that Safari does not allow keeping cookies in iframe.

It means that if you need to use cookies, you need to do something.

The solution I found is this:

  1. In the iframe code check if session[:safari_cookie_fixed] exist. If not, render a code that will communicate using postMessage with the parent window and let him know that we need a redirection.
  2. The parent window send a signal via postMessage to the iframe when the iframe is loaded. The listener, which was rendered in case the cookie does not exist, send a signal to the parent to perform redirect, and the parent does a redirection to /set-cookie page in the iframe domain, adding its current url as a query-string parameter.
  3. set_cookie action save a cookie safari_cookie_fixed and redirect back to the parent page (which its url is available in the query-string)

Of-course this solution requires adding some js code in the parent page, but when you give your user the iframe html code you can include the js as well.

mb21
  • 34,845
  • 8
  • 116
  • 142
guyaloni
  • 4,972
  • 5
  • 52
  • 92
  • but this results in a redirect and then reload of the entire parent page, right? Somehow the facebook like-button plugin manages to do without, even if third-party cookies are disabled... – mb21 Aug 18 '16 at 12:54
  • As described this approach is a security risk. It creates an open redirector. You MUST whitelist the URLs passed in the query string to only those that you trust. https://www.owasp.org/index.php/Top_10_2013-A10-Unvalidated_Redirects_and_Forwards – phylae Oct 03 '16 at 14:40