![]() Usually a better solution is either to redirect the browser to the signing ceremony’s URL, or to open a new tab in the browser for the signing ceremony. Similar to the issues for using a DocuSign embedded signing ceremony, the OAuth security standard prohibits iframes. These days, especially for an embedded signing ceremony, iframes are rarely needed: they provide an inferior trust user experience, since the signer can’t see the DocuSign URL they enable clickjacking and they don’t support some important DocuSign features such as Identity Verification. There are multiple layers to solving the problems the new browser policy exposes: Don’t use an iframe With the new setting for the Referrer-Policy header, the referer header no longer includes query parameters from the referring website. But in the interests of backwards compatibility, the incorrectly spelled referer header remains.) (Yes, the header’s name should have been spelled correctly in the first place as the referrer header. The new referrer policy primarily affects developers who are examining the referer header to check the event query parameter sent by DocuSign when an embedded signing ceremony is completed by the signer. ![]() This is because DocuSign uses the browser’s default referrer policy. Additional browsers are also expected to adopt this policy in the future.Īs the new default policy setting is rolled out and customers update the browser on their computers, tablets, and phones, some DocuSign developers are discovering that their applications are no longer working properly, especially with some patterns of using iframes. Multiple browsers, including Chrome for desktop, Chrome for Android, Firefox, and Microsoft Edge, have updated or are planning to update their default for the Referrer-Policy HTTP header to the more secure strict-origin-when-cross-origin setting.
0 Comments
Leave a Reply. |