0

I have a rails 4 application that loads an iframe in one of the views. I'm testing my app on staging using safari (it works on Chrome and Firefox) and I'm experiencing an X-Frame-Options rejection error. Inside of my developer tools in Safari, when I load the iFrame view I am receiving:

Refused to display 'https://demo.docusign.net/Signing/(X(1)S(xxxxx))/SessionTimeout.aspx?fi=xxxx' in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'.

I don't receive this error in Firefox or Chrome.

My rails code is as follows:

# application_controller.rb
def allow_iframe
  response.headers.delete('X-Frame-Options')
end

# iframe controller
before_filter :allow_iframe, only: [:show, :signing_response]

Any guidance on this issue would be appreciated.

Questifer
  • 1,113
  • 3
  • 18
  • 48

1 Answers1

4

The root cause here isn't your server or Rails configuration, or even intrinsically tied to Safari....its because the web browser is blocking 3rd party cookies.

In an embedded signing workflow, the DocuSign window within the iFrame will try to drop an authentication cookie on the signers machine. Since its coming from demo.docusign.net, the browser considers this a 3rd party cookie (versus 1st party cookies which is what your server/domain drops directly). Safari blocks 3rd party cookies by default where almost all other browsers allow them by default.

If you look at the error URL, note the following:

  1. demo.docusign.net is whats refusing to be displayed in an iFrame because IT is what set the X-Frame-Options header, eg the header issue is from the DocuSign URL, NOT your server pages (including whatever you passed or set for returnURL).
  2. SessionTimeout.aspx? is on the URL not the normal SigningStart param...this is because the cookie was blocked and DocuSign has invalided the signing URL

You can reproduce the issue on Chrome for testing verification by following the instructions here: https://support.google.com/chrome/answer/95647?hl=en to set it to block 3rd party cookies.

Note you may see inconsistent results in testing because if a valid DocuSign cookie is already on the clients machine, the browser may not consider it 3rd party anymore and allow the new authentication cookie to drop, allowing the signing window to load successfully

Unfortunately there are no good, 'turn-key' solutions. Your options are:

  1. If you can control or influence your client browsers' settings (like in a corporate network) you can set them all to allow 3rd party cookies or whitelist docusign
  2. Open the signing window in a new tab or popup. This is probably the best approach but can complicate user experience and if you use the JS / popup route (vs target='blank' for a new window), it has the potential to get stuck in ad / popup blockers. See here to help get around that if you go the JS route: Bypass popup blocker on window.open when JQuery event.preventDefault() is set
  3. some set of custom hack / workarounds to get the cookie placed first and then reload the signing window. These have has varying degrees of success but the root issue is the same as a lot of Facebook apps:

More resources:

Community
  • 1
  • 1
343_Guilty_Spark
  • 146
  • 1
  • 5
  • This is a very thorough response. You're dead on about the the inconsistent testing results- it's been confusing me all day long. I will need to consult the DocuSign documentation to see if I can send the user to their site for signing and then redirect back to my app on successful signing. Thank you for the helpful answer. – Questifer Sep 22 '15 at 01:36
  • We've been battling the exact same issue with our app since late last week :) We're currently experimenting with a JS solution that pops open a quick popup (using the technique above) and closes it in say 1-2sec to try to land a "priming cookie", and then use a 2nd get signing URL API call for a new embedded signing view URL and load that into the iFrame. I'm not sure exactly what changed late last week but I suspect it was a cookie change on DocuSigns end. – 343_Guilty_Spark Sep 22 '15 at 02:50
  • It started breaking for me late last week as well. We're getting flooded with users saying they're experiencing issues w/ Safari. Regardless of the cookie change on DocuSign's end, how come it worked before? If Safari blocks 3rd party cookies by default then shouldn't the cookie used earlier have been blocked? Or does Apple somehow approve some 3rd party cookies? We rely very heavily on embedded signing for our application so this timing is unfortunate. – Questifer Sep 22 '15 at 03:03
  • That still bothers me too. The speed of the onset makes me think it was something like a DocuSign change in their internal authentication process that had allowed them to slide under the radar before (maybe not intentionally or known) as opposed to a Safari update. We were running down Safari specifically too until we had a Windows/Chrome user report the issue (corporate environment). I then came across this old post - http://stackoverflow.com/questions/17955117/embedded-signing-with-safari-on-mac-not-working-as-intended . Stranger then ever since that post was from 2013. – 343_Guilty_Spark Sep 22 '15 at 03:59