We are trying to display the sender view via embedded signing in a http based intranet web application. But DocuSign is returning an https based URL for sender view & when we are trying to display it in iframe we are getting a session timeout window in DocuSign.
We cannot host the intranet site in https.
Any work around for this?
Instead of embedding DocuSign an iFrame, launch the DocuSign URL in a new window/tab. Doing so (i.e., using a new window/tab -- NOT an iFrame) is actually best practice for a number of reasons, including:
iFrames do not typically provide a good user experience on mobile devices
some types of browsers have issues with displaying DocuSign within an
iFrame (do to security restrictions that are typically enforced by
browsers for third-party apps operating within an iFrame)
The DocuSign API documentation actually recommends against using iFrames, specifically within any app that will be accessed via mobile device.
Related
I want to use DocuSign dll to sign the document but I don't user to redirect to DocuSign portal, is there any way to customize the DocuSign dll.
Well, there is not much to me to go by, so here are some thoughts.
You don't have to redirect, you can instead embed in an iframe. this may solve the issue if your concern is that the URL is visible in the browser as DocuSign vs your URL.
However, if you just don't want to use a cloud provider then you need to use DSA (DocuSign Signature Appliance) which means you'll get a set of servers that you have to maintain by your IT dept and in theory you can have your users sign documents without connecting to the internet.
You can brand the DocuSign signing ceremony to match your site's colors, fonts, add your logo, etc. See the branding docs
The signing always takes place at the DocuSign website. It can be embedded in an iFrame as Inbar mentions, but iFrames introduce their own issues.
The client side flow described here was working in an iframe until about a month ago. We are working from an Modern SharePoint environment (SPFx webpart) and Yammer Office 365 Identity Enforcement is Enabled so when I am logged in to SharePoint/Office 365 the iframe should automatically authenticate and return to the configured redirect page with my token. Currently it is moving me to https://www.yammer.com/session/new where I will need to login, which off course will not work in an hidden iframe. I see the same behavior in an popup in Chrome (also taken to the session/new page). The popup login in IE is working though (while the Iframe isn't).
Lot's of our customers find this popup disturbing and on most browsers popups also aren't enabled automatically. Therefore lot's of users aren't authenticated to the Yammer API and some of our functions (like showing comments, commentscount etc) aren't working as expected. The iframe login was providing us with the possibility to login silently.
Can someone help us out or point us in the right direction? Many thanks in advance!
More information and a uservoice:
https://github.com/SharePoint/sp-dev-fx-webparts/issues/790
h
https://yammer.uservoice.com/forums/399627-yammer/suggestions/36909883-add-support-for-an-iframe-login-to-authenticate-to
I am trying to load content in a WebView in my Windows Phone 8.1 RT app. As per requirement, I need to fetch the content from database and render it in the WebView. The content is essentially an HTML document (with inline javascript and CSS) saved as a string in database. It also makes connection with mobile service.
I have added * in my mobile service's CORS whitelist. I also added null after discovering that it was required for the app's android and iOS counterparts.
I am using NavigateToString() method of WebView. It is not able to fetch data from azure because it sends about: as origin in the request header (possibly from about:blank). I need to add about: in whitelist but it won't allow because it says it is not a valid hostname. I added about* with no success. What should I add in CORS whitelist now, considering I already added *?
I'm assuming (slightly) that this is a WinJS application. It actually has nothing to do with Azure or your Mobile Service. It's got everything to do with the requirements within a WebView.
Review: https://msdn.microsoft.com/en-us/library/windows/apps/hh465373.aspx
That link provides the yes/no for your request - in a WebView you are doing a Web context. Note explicitly that you are doing Cross-Domain XHR requests are those are explicitly forbidden.
Can we navigate signer who is on a Mobile device (Salesforce 1) to a visualforce page when the document is signed and the submit button is clicked?
Yes you can accomplish this. You'll need to use the DocuSign API and more specifically, the Embedding functionality which will allow you to sign through a webview or an iFrame on the mobile device.
With Embedding you can control the redirects URLs based on actions the user takes. For instance, if the user signs you can navigate to the Visual Force page in question. Or, if the user declines to sign then you can navigate them to a different page if you'd like. Same thing for if they hit the X to close the signing window.
To get started with learning DocuSign's APIs check out the DocuSign Developer Center:
http://www.docusign.com/developer-center
And for code samples of Embedded Signing in 6 different language stacks see the bottom 3 API Walkthroughs in the API Tools section:
http://iodocs.docusign.com/apiwalkthroughs
I need to show an external site through our sharepoint portal and have added a Page viewer web part. The problem is that the address includes a login and password used to autologin to the external site but Sharepoint only shows the login page on click.
If I click the "Test link" in the web part properties it opens as it should but in a different window and not in the sharepoint frame.
The adress has the format http://www.site.com/companyname/Login.aspx?style=companyname&lang=en&l=login&p=password
How can I get the autologin to work in the frame used on my webparts page?
Any help very appreciated.
With regards
Marcus L
Assuming you are using Internet Explorer, the problem is with IE's security policies.
The Page Viewer Web Part is basic and pretty much just inserts an IFRAME tag into the page with the URL you have supplied. This displays your external site in a child frame.
By default, child frames cannot store cookies for use by the parent. The URL you are passing through to the external site contains the username and password which is fine, however the site needs to store a cookie so it knows you have logged in as you browse other pages within it. As it can't store the cookie, the child site assumes you have not logged in.
You could test this by adding the external site to your Trusted Sites list in IE and set the Trusted Site security to Low. Then it should be able to store the cookies it needs. Alternatively if you have control over the external site, this KB article may help you.