Earlier quoted context omitted.
I understood it as they were using the API for validation but loading the embedded content straight from DS, in which case they wouldn't be able to control whatever's displayed in the embed.
A user goes to a page and sees DocuSign view 1. Now they refresh and see DocuSign view 2 that shows everything. How did they get they get view 1 and why couldn't they do it again on refresh?
Lessons from Failed DocuSign Integration
31–40 of 85 posts
Re: Lessons from Failed DocuSign Integration
#32Earlier quoted context omitted.
>No, their embedded view is hosted on their site. Right, but aren't you telling them which view to show? For example, show document X for the user to sign.
Yes. The problem is that on page refresh, that constraint is lost and the user is logged into the account, in DS UI. They can click around anywhere at this point, outside of the page we specified.
Re: Lessons from Failed DocuSign Integration
#33Earlier quoted context omitted.
>No, their embedded view is hosted on their site. Right, but aren't you telling them which view to show? For example, show document X for the user to sign.
Yes. The problem is that on page refresh, that constraint is lost and the user is logged into the account, in DS UI. They can click around anywhere at this point, outside of the page we specified.
Why can't you put this constraint in a session and pass it back in on refresh?
Re: Lessons from Failed DocuSign Integration
#34Earlier quoted context omitted.
A user goes to a page and sees DocuSign view 1. Now they refresh and see DocuSign view 2 that shows everything. How did they get they get view 1 and why couldn't they do it again on refresh?
View 1 comes from us (see my reply to your comment below). As for your 2nd question - that is the crux of the problem we had.
Re: Lessons from Failed DocuSign Integration
#35I remember having to call them asking where to find a template ID so I could save that and send out the proper doc to customers. It was not listed anywhere on the developer dashboard. The rep told me in a very condescending way that it template ID was part of the URL. I should have known to just use that!
My app was written in a python backend. They had a some API examples in different languages for their docs. The python example was a total embarrassment. It was clear that the person who wrote it had no experience with python at all. I am not trying to be mean, it was that bad. Every line ended with a semicolon (in python this is not an error, but is officially discouraged). The person also seemed to not be aware of a dictionary. They built their json paylod by concatenating text. It was the messiest python code I had ever seen. I think this particular bit of code is gone now, but it was incredible.
I felt so bad that I emailed them some suggested fixes and asked if they had python experience. They responded with a something along the lines of ya, we had the java guy do that. But the code stayed up there for a long time...
Re: Lessons from Failed DocuSign Integration
#36Earlier quoted context omitted.
View 1 comes from us (see my reply to your comment below). As for your 2nd question - that is the crux of the problem we had.
If View 1 comes from you why can't you give it back to the user on refresh?
A sophisticated enough client user would still have access to the all data associated to the API user.
Re: Lessons from Failed DocuSign Integration
#37Earlier quoted context omitted.
Yes. The problem is that on page refresh, that constraint is lost and the user is logged into the account, in DS UI. They can click around anywhere at this point, outside of the page we specified.
>The problem is that on page refresh, that constraint is lost Why can't you put this constraint in a session and pass it back in on refresh?
Re: Lessons from Failed DocuSign Integration
#38Earlier quoted context omitted.
Yes. The problem is that on page refresh, that constraint is lost and the user is logged into the account, in DS UI. They can click around anywhere at this point, outside of the page we specified.
I'm curious as to how HelloSign guards against this. Do they have some sort of session token that sends you back to the signing page on refresh? (i.e. similar to guard to avoid submitting shopping cart purchases twice).
Re: Lessons from Failed DocuSign Integration
#39Earlier quoted context omitted.
Yes. The problem is that on page refresh, that constraint is lost and the user is logged into the account, in DS UI. They can click around anywhere at this point, outside of the page we specified.
I'm curious as to how HelloSign guards against this. Do they have some sort of session token that sends you back to the signing page on refresh? (i.e. similar to guard to avoid submitting shopping cart purchases twice).
Re: Lessons from Failed DocuSign Integration
#40I was on this project and can speak a bit more on the technical details here. A couple of high level goals: 1. We wanted to use their embedded flows, to keep the experience within our application as much as possible. 2. We wanted to avoid having to create a DS user for every user in our application that turned on this feature. We were looking for using 1 “API user” to make requests, handling data scoping ourselves wi…
You may come and go bankrupt but your customers have to hold their own contracts on file for the life of the contract plus N years depending on their jurisdiction (eg 7 years).