Duo_Liang's account

Hi Mark, If you require your sender's signature, and want to send an email to your sender(record owner), you can follow the Notify Signers Guidance to manually send an email to your sender's mailbox once you sent your package. But you can always generate an authentication token and use this token to combine the signing URL by your self and integrate the signing ceremony in your own work flow. For more information, you can follow this guidance. And if you just that link from email, it's signing url, guidance here. The difference between these ways is, the signing url won't be expired and all authentication tokens will expire in 30 mins depending on your needs. Hope this could help you! Duo

Hi Mark, Was our support team member able to reproduce the issue or if it's only happening in your ORG? If the issue remains, I would suggest the workaround that the sender to sign through our WebUI while our support would work with you on this issue. And from the OneSpan Sign SFDC connector, the sender should know when they send a transaction, so that's how they will know when they need to sign one. Hope this could help you! Duo

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

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

Hey senthilnatarajan, For signature formats, there's separate settings for all languages, which is at your account level that has to be changed by our support team. So simply send your account's email and your request to [email protected] and our support team would change your English version's signature format accordingly. Duo