The problem that is solved here is that Safari on iMac blocks 3rd party cookies by default. Also on ipad (Prevent Cross-Site Tracking) and Firefox (Accept only cookies from visited pages) the browser can be configured that you need this workaround! So if your page in the iframe needs cookies you should continue reading.
Also cookies in iframes need to be secure and have the attribute SameSite=None set!
Please see here: https://www.tinywebgallery.com/blog/advanced-iframe/advanced-iframe-pro-demo/how-to-use-the-samesite-cookie-fix
Advanced iFrame Pro does now support the “Safari 3rd party cookie in iframe workaround” described at http://vitr.github.io/safari-cookie-in-iframe/. I have integrated this workaround and also enhanced it that you also can apply this for all browsers! So please read the page from vitr first. All the credit for this solution goes to vitr!
If the page in the iframe does require cookies to work properly you should try to apply this fix. The solution does a redirect once to a page on the domain where the iframe is located. This does set a cookie and redirects back to the original page which is then properly loaded. So you have one additional reload for the browsers you configure.
The configuration for this fix can be done in 2 ways depending on the access rights you have on the remote server. This can all be configured in the administration on the “Advanced Settings” tab -> “Advanced features” at “Safari cookie fix” or with the short code parameter safari_fix_url:
- Copy a file to the remote server. This is the preferred way as the provided wp-content/plugins/advanced-iframe/includes/_safari_fix.html has only a few bytes and is loaded really fast. Copy this file to the same domain as the iframe. Set safari_fix_url=”<path to _safari_fix.html>”. Only the url without /_safari_fix.html has to be set..
- Usage of the external workaround. For this the whole iframe page with all assets has to be loaded. The overhead is most likely really huge compared to the _safari_fix.html. But sometimes this is the only option! As this is only done once per user this often is also acceptable. You need to apply the external workaround and set _safari_fix.html=”src”.
- You don’t have access at all to the other server: The fix cannot be applied.
What else does this solution offer?
- Support for all browsers:
Most browsers you can configure that 3rd party cookies are accepted, blocked or to accept 3rd party cookies from visited sites only. Currently Safari is the browser that has the default the 3rd party cookies from visited sites are accepted. But you never know how the user does configure his browser! Also browsers behave differently if you are on a sub domain or a remote domain. This can be activated by adding all: to the safari_fix_url. e.g. safari_fix_url=”all:src”
- Show a message in case of a problem:
The offered solution can be configured that a configurable message (default: This website requires that third-party cookies are accepted. Please change your browser settings that at least “from visited” cookies are allowed.) is displayed to the user if even after the fix no cookie can be used. If your page does depend on cookies this is the best you can do. Normally this should only appear for users that have changed their settings manually. This can be activated by adding message: to the safari_fix_url. e.g. safari_fix_url=”message:http://www.mdempfle.de/fix”. It can also be combined with the setting above: safari_fix_url=”all:message:http://www.mdempfle.de/fix”.
The next demo’s show both ways how to do the setup in detail. If the workaround is applied once you need to delete the cookies “aifixed” and “aichecked” from www.tinywebgallery.com and the cookies “safari_cookie_fix” and “the_cookie” from www.mdempfle.de to try it again. Otherwise also the example without a fix is now working. The solutions are configured to show the message and to work on all browsers. Only the Safari one only applies the fix for Safari. On the example pages are explained how to only apply the fix for Safari and without a message.
PS: If you want to test this whole feature here and you don’t have a MAC I recommend to test with Firefox because there you can set all 3 possible values for the 3rd party cookies!
Like always IE is behaving differently! To allow cookies inside a iframe p3p header needs to be set. You can google a lot about this issue but the best solution I have found is to set:
header(‘P3P: CP=”ALL DSP NID CURa ADMa DEVa HISa OTPa OUR NOR NAV DEM”‘);
To the page in the iframe. This header is set in the plugin already for the parent. But the already set header only works if you share your content like shown in “Add ai_external.js local“. For any other setup you have to include the header manually. If the page in the iframe is also WordPress you can also use a plugin like HTTP Headers and set the p3p header there.
- aifixed: This cookie is used on the parent domain to check if the fix was applied already.
- aichecked: This cookie is used on the parent domain to check if the fix works. This is only used if you show a message in case of a problem
- safari_cookie_fix: This cookie is used on the iframe domain and needed to tell the browser that you have already visited the domain directly and allow therefore 3rd party cookies
- ai_test_cookie: This session cookie is used on the iframe domain to check if the warning message is needed. It is deleted right after the check again.
- the_cookie: Is the test cookie of the page in the iframe. You have your own cookies here!