Safari Websocket Connection Problems in iframe - endless reload

I have an app where we allow parts of the app to be embedded into other pages. This all works in Chrome, Firefox but not in Safari. In Safari we see an endless reload of the iframe. In the console we don’t get any error or warning. We’ve set CSP policies frame-ancestors and connect-src for both the app itself and the embedding frame.

The websocket connection join request fails with

 {response: {reason: "stale"}, status: "error"} 

The app itself works properly in Safari (and all other browsers) only embedded in Safari causes this error.


we got the exact same problem. Everything works as expected until we embed the app via an iframe. Every browser works except safari. We get also the response

{response: {reason: "stale"}, status: "error"}

Did you solve it?

We set the frame-ancestors, the connect-src. We also set the session cookie option same_site: “None“ and set the secure attribute by setting same_site: "None", secure: true.

No, unfortunately not. Still looking for a solution… It’s not the highest priority therefore I could put it aside for a while but need to solve it. Let me know if you make progress.

The reason is the default behaviour of safari, iframes and cookies. It blocks third-party-cookies in iframes. (Prevent Cross-Site Tracking)

You can test it by visiting your site, where the broken iframe is included. Then go to safari preferences → privacy and uncheck the “Website-Tracking“ checkbox. Your app will work fine afterwards.

Thats no solution, just for verifying the reason.

Found this with fast googling Safari iframe cookie workaround · GitHub

Thanks for pointing out the problem and links to the solution. Have to say that all is not really good for our solution where we don’t have much influence on the embedding site…

I’m not sure if this has any help to you. But how our company’s software uses cookies is by only having one cookie that contains JWT token with unique client id. Then we tie everything to that client id, like authorization when user is logged in. So instead of using multiple cookies as such we only have one cookie that identifies the browser. Instead of cookie you could also use local storage then send that in LiveSocket params on connect. Of course that is not as secure as http only cookie.

Edit: Actually I’m not sure if you are even using LiveView :wink: But maybe Phoenix Channels or what ever you are using could also support this.

thanks for the additional thought. actually if that is only cookie related I think I just need to remove all cookies in our pipes that are not needed in our case.