mvonahn's account

Is there a way to make use of the included mobile navigation when not on mobile? That would fit our needs quite nicely.

Thank you for the response. Does this equate to setting the type to "Capture Signature" in the sandbox web ui?

Ah, that is what I was afraid of. What happens in this case is the first signature is actually "signed" the user has to draw their signature. Then every other signature block for that role that is set to "capture" just stamps that first signature in (this is what I meant above as the "click to sign", poor term since that is already used to mean something else in the product). We need to be able to force the user to draw their signature again after the first one (legal requirements)

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.

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?