Live data from Hacker News

Lessons from Failed DocuSign Integration

profsmallpine.com

31–40 of 85 posts

Re: Lessons from Failed DocuSign Integration

#31
post #29

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?

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

#32
post #28
post #25

Earlier 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.

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

#33
post #28
post #25

Earlier 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.

>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

#34
post #31
post #29

Earlier 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.

If View 1 comes from you why can't you give it back to the user on refresh?

Re: Lessons from Failed DocuSign Integration

#35
I had a project that used docuSign a few years ago. There were some very strange things going on with their API.

I 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

#36
post #34
post #31

Earlier 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?

Even if they added this feature, the API bug would still remain (it would just be covered up by the UI).

A sophisticated enough client user would still have access to the all data associated to the API user.

Re: Lessons from Failed DocuSign Integration

#37
post #33
post #28

Earlier 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?

View 1 is on the DS domain. We have no control once the user is in there aside from giving the redirect URL.

Re: Lessons from Failed DocuSign Integration

#38
post #32
post #28

Earlier 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).

[deleted]

Re: Lessons from Failed DocuSign Integration

#39
post #32
post #28

Earlier 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).

HelloSign's embedded signing happens in a iframe, through their JS client. The user is never directed to HelloSign's site unless you choose to to an un-embedded workflow.

Re: Lessons from Failed DocuSign Integration

#40
post #14

I 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…

It’s an esignature application. Of course by law you have to create a Docusign user for each record holder.

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).

Post reply on HN