Cookie issues on Safari

Hey Chris, I've been meaning to post something about this. This is a known issue and as you said, it is only happening with Safari, it seems. If you are using any of the e-signlive instances (sandbox.e-signlive or apps.e-signlive), there has been a solution put in place to help work around this issue. There is a "loading" page set up on these instances that allows you to establish the connection with eSignLive before the session is opened. You would just need to do something like this:

 html >
   head >
     script >
      var myWindow;
      var windowUrl = "https://sandbox.e-signlive.com/html/loading.html";

      // Insert your signing session URL here with the session token.
      var authUrl = "https://sandbox.e-signlive.com/auth?...";
     
      function launchSigningCeremony() {
        myWindow = window.open(windowUrl, "MsgWindow", 'toolbar=no, status=no, menubar=no, scrollbars=no, resizable=no, left=10000, top=10000, width=10, height=10, visible=none', '');
     
        setTimeout(function () {
          myWindow.close();
           top.document.getElementById('eSignFrame').setAttribute("src", authUrl);
        }, 5000);
      }
     /script >
   /head >

   body >
     button onclick="launchSigningCeremony()" >Launch Signing Ceremony in iframe! /button >
     
     iframe id="eSignFrame" src="" width="50%"  height="400" frameborder="2" > /iframe >
 /body >
 /html >

Thanks Michael, this worked like a charm!

UPDATE: This solution is not just for Safari users. If a company policy is to not allow 3rd party cookies unless the site has been visited and a user cannot change this setting on their browser as it's locked by the admin, this issue will also occur. Note: If third party cookies are blocked completely, an embedded session cannot be used and you will need to supply a direct link to the signing ceremony.

Hello, We are actually integrating eSignLive into an iframe on our solution and we were very surprised to discover that the iframe is opening blank on Safari iOS and Mac OS . I can't believe that all the eSignLive iOS compatibility depends on that workaround ... We are actually using lot of third parties plugins in iFrames and we never met this kind of issue. The problem is that the modern browsers are not allowing opening of popups as described on your workaround without requiring an extra unwanted authorisation from the user (which don't understand). So please could you provide a real working strong update or code that we could use to make eSignLive working with iOS as others online services provide ? Thanx.

Hello Michael, We have used above code to resolve the issue on Safari browser with IPAD device , but we are still facing issues to open signing ceremony in iframe. Please find some of the observations as below: 1. When we are trying to open by clearing cookies and cache and keeping Default setting of Cookies as "Allow from website I visit", signing ceremony is not visible, we can see blank screen. 2. With above mentioned settings ,when user is trying second time to open signing ceremony again, it is opening fine. Could you please suggest what changes should we do, so that first time only, user should see signing ceremony? Another observation, when we make Cookies settings as "Always Allow", it is opening perfectly fine. But as per requirement, we don't want user to change device settings. Thanks, Pratik Palkar

Hi Pratik, What do you mean by "opening by clearing cookies and cache"? Do you mean opening Safari on an iPad, clearing cookies, and then trying to open the signing ceremony? Because I just did a quick test and it worked for me.

Hello Haris, Please find scenario as below: Lets consier the scenario, user is trying to open first time the signing ceremony and he has cleared his cache from Safari browser. That means he doesn't have anything in browser history. An while the default setting of cookies is "Allow from website I visit" with above settings, user is not able to open signing ceremony. Please let me know if any more details required. Thanks, Pratik Palkar

Hi Pratik, I tested that scenario and it was working fine for me (on an ipad). The sample code above creates a new window/tab and loads "https://sandbox.e-signlive.com/html/loading.html", which sets the cookie. And then the iframe should load fine. Make sure that the loading page is the same instance of the signing ceremony. In other words, if your package is on production 11, then you should be using https://apps.esignlive.com/html/loading.html

Hello Haris, Good morning! Thanks for your inputs! We have tried with new URL as well, but it is still not opening in Safari browser. Few observations about Loading page with other browsers: 1. Mozilla - working fine 2. Chrome - working fine 3. IE - Loading pop page is remaining after opening the iframe, it is not closing automatically which was not expected 4. Edge - Loading pop page is remaining after opening the iframe, it is not closing automatically which was not expected Could you please provide your thoughts? Regards, Pratik Palkar

We heavily use one span for signing documents using ipads (on the order of 30k documents a day) and this has effected us too. As soon as iOS 13 (or iPadOS 13) hit we had a rash of support calls about blank iFrames on new devices or devices that had been cleared. Luckily we discovered loading esignlive.com in a tab first will allow the iFrame to load until the next time the browser history is cleared (this is done nightly at some locations). Upon further investigation we have noted that there is a header difference in the 2 sessions. Without the cookie we are receiving header 'X-Frame-Options' set to 'SAMEORIGIN' and with the cookie we do NOT receive this header and everything works This may be an nginx setting or a web server setting. Also note, that ALL browsers on iOS are effected because the all use the same web kit provided by Apple.

Hi mvonahn, Let's elaborate the cookie issue in iOS a little bit: Take Safari for example, if you didn't turn off the Safari setting "Prevent Cross-Site Tracking", the third party content provider (OneSpan Sign domain) won't be able to grant browser cookie, unless you visit and interact with the third-party content provider as a first-party website. (that's why we have this workaround that you just need to open any page from OneSpan Sign domain once in a new tab, either programmatically or manually) Before iOS 13, if you've turned off the "Prevent Cross-Site Tracking", you won't have any problem accessing signing ceremony within an iFrame, however after iOS 13, there's one security update mentioned in Safari 13 release note that might still prevent the third-party cookie:

Updated Intelligent Tracking Prevention to prevent cross-site tracking through referrer and through link decoration.

(From the best of my knowledge, OneSpan Sign signing ceremony pages used referrer) Since it's a main trend for Safari to have more and more restricted controls on third-party cookie, I won't think there's an easy fix to by pass it. So I would suggest a potential solution which is currently used by one of our biggest client and partner: that to leverage a Reverse Proxy converting the third-party cookie to first-party cookie. I had a blog Third Party Cookie and Reverse Proxy guiding you through how to configure the apache server, kindly have a check there. Hope this could help! Duo

Could this same thing be resolved with an X-Frame-Options: ALLOW-FROM header? something configurable once and not need the complexity of adding a reverse proxy to the communication?

Hi mvonahn, Please note that the "X-Frame-Options" header is not the cause of this issue, the root cause is the fact that the Signing Ceremony page was not able to grant third-party cookie to your browser, therefore the page was redirected to the login page, which is displayed as blank page. Login page is not allowed to be embedded into iFrame, therefore you've seen the same origin restriction. Below, I will clarify the whole procedure in a detailed manner: Above screenshot represents a typical failure when trying to access an embedded Signing Ceremony, due to the cookie issue. As you can see, there're two redirect jumps after the initial request: if third-party cookie is enabled and successfully be granted, the last call should lead you to the actual signing ceremony page, while in the failed scenario, due to the lack of cookie header(ESIGNLVIE_SESSION_ID={your_session_id}), the error handling in Signing Ceremony code kicked in and redirected to the login page. Please let me know if this is consistent to your scenario. Duo