11–20 of 85 posts
> we’ve tried to build as much as we can as to skip dependencies, I’ve spent enough time in rails to appreciate debugging owned code - an argument for another time... Okay, I'll bite. I have no experience in RoR, but does this line suggest that RoR encourages NIH? This line feels like that scene in a horror movie, right at the beginning, when the camera lingers a little too long on the janitor's face as he cracks a s…
What is NIH?
> we’ve tried to build as much as we can as to skip dependencies, I’ve spent enough time in rails to appreciate debugging owned code - an argument for another time... Okay, I'll bite. I have no experience in RoR, but does this line suggest that RoR encourages NIH? This line feels like that scene in a horror movie, right at the beginning, when the camera lingers a little too long on the janitor's face as he cracks a s…
What is NIH?
>I was annoyed that they didn’t provide a secret key to authorize API requests
Yeah... they don't do that for a reason. They appear to support a fully fledged OAuth implementation (https://developers.docusign.com/esign-rest-api/guides/). I haven't used it, so maybe it's terrible, but I'm suspicious of the author at this point.
>DocuSign API docs are very quirky
But no discussion of why, or what he would expect instead. This actually sounds like the author is lost because they don't understand OAuth again (and to be fair, I've implemented OAuth and it's easy to get wrong).
>Someone on the team noticed that if you refresh the page, you get logged in as the user that was making the API request. [...] About a week later, we were informed that this is intentional, and they were worried about breaking anyone that is using this as a feature.
This honestly sounds like they were politely telling you that you haven't implemented OAuth correctly. You should be making the request with the token of the delegated user, not a generic account.
>I got this working, but it took some janky work to re-work the JWT flow to manage hourly expiring tokens for all of our user that choose to enable the esignature feature.
This is what refresh tokens are for. I highly doubt the refresh token expired in an hour, but hey - I haven't used it so maybe I'm wrong.
---
I honestly believe I can summarize this whole article as: Dev takes first steps into OAuth and gets lost...
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 within the application.
The actual issue in more detail:
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).
At this point (as the OP called out), we realized we had no choice but to create DS users. But we still wanted to hide this process from our users, keeping DS as embedded as possible. The issue was their “regular” user creation flow involves a email going out to the user to confirm - obviously this is unideal if our goal was to wrap DS and hide it’s existence as much as possible from users.
DocuSign offered a workaround for this, which involved basically getting shifted to a legacy version of the API, with no hard promise of it not being sunsetted. By then, we had had such a poor experience with non-answers from their team that we called it quits.
I hope this clarifies some of the technical problems we were trying to solve for.
Edit - I'm sure DocuSign can solve for some use cases. Obviously, they have a large user base and I'm sure most of them are at least satisfied, if not happy. But if you're trying to wrap an e-sign provider within your application, I would recommend HelloSign 1000x. HelloSign's API is a first class citizen whereas DocuSign's felt more like an afterthought.
I've done a docusign implementation, and I don't really agree with them. Their API is fine honestly, I think their documentation could be better and some things are named awkwardly. But the implementation really isn't hard, my only real complaint is that when we did it they pushes the DocuSign connect service really hard, which honestly was kind of a waste and didn't live up to many of their promises, but that's norm…
Whether an API is "good" or "bad" often is dependent on the requirements of the calling client. At the beginning of projects when client requirements are unclear, it is often hard to determine whether a supporting API/library truly meets your needs.
Maybe the goal here wasn't to be technical (although I'm not sure why given it's an article about docusign api integration) but this is a WHOOOOOLE lot of text with basically nothing worth reading. >I was annoyed that they didn’t provide a secret key to authorize API requests Yeah... they don't do that for a reason. They appear to support a fully fledged OAuth implementation ( https://developers.docusign.com/esign-re…
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…
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…
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.
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 in prod.
They had a legacy instance and a v2 instance (w/ new UI). Enterprise integration was against the legacy instance. Accounts created in one instance does not carry over to the new instance. User who self registered in new instance some how makes authentication into the legacy instance very difficult.
As a user with admin access to docusign, there were a paltry of user management features. I had to delete individual users. No way to filter or batch any user oriented actions.
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…
>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?