Lessons from Failed DocuSign Integration

Post by EpicEng » Thu, Jan 24, 2019, 5:42 PM UTC

nowarninglabel wrote: post #6

The author seems to have buried the lead here: "Someone on the team noticed that if you refresh the page, you get logged in as the user that was making the API request" And that is how the implementation works for many of Docusign's customers as a 'feature'. If that's true, that would seem like a potentially exploitable security hole. However, I'd have to question if that had something to do with the particular imple…

Post by stronglikedan » Thu, Jan 24, 2019, 5:45 PM UTC

treis wrote: post #20

inoda wrote: 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…

>1. Go to an embedded page, authenticated as the “API user” (which looks like you’re sandboxed within DS to the embedded page) >2. Refresh the page >3. You now can click around the entire account - viewing any data that belongs to the API user (in our case, all of the data). I don't quite understand this. Shouldn't you be able to control what is displayed during the refresh?

Post by rblatz » Thu, Jan 24, 2019, 5:46 PM UTC

inoda wrote: post #18

rblatz wrote: post #17

Earlier quoted context omitted.

We did exactly this integration, it was fairly seamless. I walked a Jr dev through the high level plan and we cooked up a POC in postman in about an hour that did a very rough bare bones version of what we were looking for. He was then able to run with that rough POC and build a production service that managed all of our docusign integration. I wonder what caused us to have such different experiences with the API.

You have definitely struck my curiosity - which version of this integration I outlined did you guys implement? 1. Embedded views + user creation w/o requiring email confirmation 2. Embedded views with 1 API User I don't want to assume anything here, but I think you either didn't build exactly what we were trying to, you are on the legacy version of their API, or you have that embedded view refresh bug I outlined live…

Post by inoda » Thu, Jan 24, 2019, 5:48 PM UTC

treis wrote: post #25

inoda wrote: post #21

Earlier quoted context omitted.

No, their embedded view is hosted on their site. The functionality is directing to them to a page on their site, with a redirect URL to our app after they are "done" there. This allows DS to be embedded into app-side workflows.

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

Post by Bamafan » Thu, Jan 24, 2019, 5:55 PM UTC

inoda wrote: 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…