CODEWITHSUNDEEP
iframedocusignapi
TJ Bandrowsky
TJ Bandrowsky

Reputation: 882

Docusign embedded in an iframe doesn't seem to obey cross site scripting directives

Just a few weeks ago, it seemed that creating a recipient view inside an iframe worked without any major complications. But during testing today, against the demo site for development, I found that the url eventually internally resolves to something that gets blocked by my browser because "This content can't be shown in an iframe. The publisher."

While the initial return URL return seems ok, it turns out that by the time the system resolves to account-d.docusign.com, what happens is that docusign is setting X-Frame-Origins: SAMEORIGIN, which would certainly block any iframe content.

However, while docusign says it doesn't recommend an iframe due to size issues and mobile experiences, it doesn't say that the iframe is flat out disallowed for say web applications. In any case, setting

viewRequest.XFrameOptions = "allow_from"; viewRequest.XFrameOptionsAllowFromUrl = myHost;

Should change the X-Frame-Origins header on the url generated by the created view request, shouldn't it?

Can anyone see what I might be doing wrong, or, was there a recent release by docusign that changed the behavior so that iFrames are flat out disallowed?

Upvotes: 0

Views: 863

Answers (1)

Larry K
Larry K

Reputation: 49114

Using iFrames for embedded signing works fine, but is not recommended in any circumstance. Instead, it is better to redirect the signer's browser to the embedded signing ceremony.

Using an iFrame does work, I checked it just now.

What doesn't work is to use one of DocuSign's identity servers in an iFrame (account.docusign.com and account-d.docusign.com)

Since your error is involving account-d.docusign.com, it means that something is messed up with authentication.

I think you'll need to do more testing to figure out what is happening. Check that you're using the url returned from the create recipient view API call.

Upvotes: 1

Related Questions