Is the baseUrl value returned per user or can it be used by all future users of the same account? I want to cache this value and as far as I can tell this is actually an account setting even though it's only retrieved after a user specific login. Any chance two users of the same account could have a different baseUrl? Just want to know at what level i really need to cache this.
thanks,
-mike
It is Per Account
Is the baseUrl value returned per user or can it be used by all future
users of the same account?
restapi/v{#}/login_information
This call will give you back the list of accounts that the username/password has access to. Along with the list of accounts, you'll receive the baseUrl for that account.
baseUrl defines two things:
The server that the account resides on
The account number
If there is a specific account that you're going to add users to, the baseUrl will be the same for future users of that account.
If you do not have multiple accounts logging into your application.
You can cache the information from this call so you don't have it in every workflow. It is mostly used for setting up new workflows and moving between Demo and Production.
If you do have multiple accounts logging into your application.
I would advise that you call this information at the start of your workflow. It'll ensure that you're calling the correct account for that user.
One thing to keep in mind, that 1 set of username / password can have access to multiple accounts. So you may receive more than 1 array as a response, your application should handle this accordingly.
DocuSign's LoginInformation method enables the implementation to provide dynamic re-direction of the clients at a macro-level.
Currently, or in the future, DocuSign might use the feature for a number of different reasons that I can imagine.
Using an undocumented "feature" (properties of the baseURL result) can result in a brittle client that may fail in the future. Be careful of the siren-song of pre-mature optimization.
The baseURL value changes only when you move from different environments (i.e: DEMO vs PROD). I would encourage you to store/cache it yes. Keep in mind when your application is ready for PROD, you will want to get the baseURL for PROD and store/use that appropriately.
Related
I have an ASP, vb.net, forms-based system. I want to allow people to use PDF documents created within that system to send them to DocuSign and out to others for signature. I have used the DocuSign SDK to build a system that works; however, I am concerned that I may not have the best setup for that.
The problem relates to the "open" nature of this system. Our users are allowed to see and modify all parts of the underlying system, including forms, coding, etc. As a result, a clientID and secret would be seeable to users. And that is concerning.
The system will need to be set to be easily used by our users. So, having users set up a developer account, setting up API settings, etc., will not be something we can reasonably expect.
It would be better if the system did all the interaction and they just had to log on to DocuSign to send the document out for signing. DocuSign has suggested becoming a partner in their referral system. I worry that will still require all the pieces (clientID and secret) that people will be able to see. But, I am not sure that is true.
Will being a partner mean we can avoid having those items saved in an open system where users can see them? Or does being a partner mean some of that is removed or not necessary?
Is there a better way of setting this up so that we can avoid all that mess?
There's no reason that all your customers wouldn't be able to use the same clientID (also know as Integration Key or IK) and secret key (clientSecret).
You will be the only one that can see/set them as the ISV. They will all use their own DocuSign accounts, using your IK. That is abosltuly fine and does not have any limitations.
We recommend ISVs use a single IK per app if it's the same code for the app even if they have multiple customers using the app.
I'm building a full-stack application with Next-JS. I'm building an API that works with Firebase. I was wondering if there is a way to make this API secure.
Let me elaborate. There is an option to your account called Premium. This variable is stored in the Firestore and will determine if you have purchased a Premium membership. This will determine whether or not you have access to certain features. I will use an API to change this variable.
I had the following in mind:
Have a button on the page to upgrade account.
Button pressed? Call to the API with the following params: email, upgrade to. This is because the same function can also be used to downgrade an account, for example when the user doesn't pay for the upgrade.
That API function changes the variable in the Firestore. It returns a status and a message.
I want to make option 2 more secure because otherwise, it would allow anyone to change the premium variable. That is obviously not what I want. Is there anything I can do about that? For example, a token system, the thing with that is that I have been thinking about that and I don't really know how to implement that and how it would work exactly.
For anyone wondering why I am using an API: I will also be creating an app, probably with react-native. The user will also be able to change their account status and interact with the API to do other stuff in that app.
Thanks for reading and responding! I hope this is at least a bit clear. If you have any questions, please comment them.
I do similar things in my app. I use Cloud Functions (which operate in a secure environment) to both save settings in Security-Rules -protected tables, as well as setting Custom Claims in the users Auth profile. All authorizations are then verified in the Cloud Functions before any changes are made - You may need to "seed" some values in a protected collection/document from the Console to get the process started.
I have a question regarding base URI with user and account objects in REST API.
To summarize:
one user can have multiple account attached,
one account is attached to one company,
without OAuth, we can get base URI by calling API /login_information,
with OAuth, we can get base URL by calling API /oauth/userinfo
Is it right ?
If yes, can we say that one base URI is attached to one account and will be the same for every user attached to this account ?
In addition, is it possible to get base URI by calling an endpoint dedicated to the account, and not the user ?
Thanks in advance for your answer.
Everything you write is correct, you understand this pretty well.
The reason you cannot use an account API endpoint to find the baseUrl is the architecture of how this works. The DocuSign code is deployed to many data-centers, but it's the same code. The same APIs run on na2, eu1, au etc. etc. So they are not aware directly that they have a different baseUri than other data centers.
The OAuth endpoints are different/separate and can get information from all data centers.
OAuth is always about a specific user, because you cannot login directly to an account, but you have your own user that you use. An account is shared, but each user has their own password.
The only way to do something remotely similar to what you're asking is if you use the DocuSign organization feature.
You can then use the DocuSign Admin API to obtain information about the organization and the accounts in it. That information includes a siteId that tells you if it's on na1, na2, eu1 etc. Using that you can construct the baseURI.
Lots of limitations to this, so not sure that would help you.
Running into a bit of an odd issue. I assume it may be a setting somewhere?
Using the API integration for embedded forms. We have two brands, so I've made two users with the same roles. Their job is to be the sender for any embedded form for their respective brand. Their roles are both set as sender from the user settings tab.
support#brand.com
support#other-brand.com
Each user is in 2 groups, developers and their respective brand. Simply being part of developers will allow them to be assigned as the sender of any API templates. It's worth noting, these two users are identical to one another in setup, only difference being support email.
Using user 1, there are no issues, and everything works as intended. Using user 2 however, I get the error "consent required" when trying to get a JWT token?
I've gone through all and any settings I could find, but nothing seems to do what I need. Both users belong to the organization, so I'm simple confused.
Any help and direction is much appreciated.
The answer was I needed to claim the #brand URL the 2nd user was under, which had not been claimed via the application admin interface.
Consent is per user, you would need the second user to log in and navigate to the URL For consent.
If you are using the developer/sandbox/demo environment (not production) the URL you would want to set looks like this:
https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature%20impersonation&client_id=<your IK>&redirect_uri=<some URL you defined for the IK>
Remember to define the redirect_uri in the Apps and Keys page in the settings page where you created the Integraiton Key and you should be good.
I have some doubts regarding the custom connector we are trying to build for docusign : -
Regarding the license plan that need to be bought by the customers who will be granting access for our connector to collect data from their docusign organization account. I am looking at the link https://www.docusign.com/products-and-pricing. API access support is mentioned in only the advanced solution. So I was wondering whether only we need to have "Advanced solutions plan with APIs support" plan or all our customers need to API access support in order to fetch their data.
As per the documentation, to make the REST API calls we need two fields 'base_uri' and 'account_id' (https://developers.docusign.com/esign-rest-api/guides/authentication/user-info-endpoints). Now, the response of userInfo API call gives an array of accounts and its respective fields. My doubt is, if multiple authenticated users (more than one accounts) are returned in this array but all are part of same organization, will they all have different account_ids. Main concern here is, will there be several Base Paths (https://developers.docusign.com/esign-rest-api/guides/authentication/user-info-endpoints#form-your-base-path) to make API calls?
2a. Further question is, what is the significance of 'is_default' field?
Is this related to main account (if is_default is true) using which we will create our Base Path?
Since this is a tech/engineering forum I'm going to answer only question #2 as question #1 is more of a business/sales question.
The reason you may get multiple accounts is that an authenticated user in DocuSign can be a member of multiple accounts. That said, it's the same user. Meaning, say foobar#blah.com has an account 123 with company X and account 456 with his school, then it's possible that when foobar#blah.com authenticates (With the same password!) to DocuSign we have a list of accounts associated with that user. We give you all of them when you make the API call. The default one is the main one that you would see when you log into our web app. You can decide yourself as the user which one is the default. Users who log into our web-app then see an option at the top-right to change accounts.
and yes, every API call is associated with a specific account. So when you construct the urls for your API - you do need to know which account for this user you are making the API call for. Your application can decide how to handle this.
Hope this helps.