As it stands in DocuSign documentation:
Update API calls to use the account's base URI You must update your integration to use your account’s base URI for API calls, instead of demo.docusign.net. You can use the UserInfo Authentication Service endpoint to get the base URI for an account.
Note: Accounts move between base URIs infrequently, so the data can be cached for a day or more.
Hier a list of the DocuSign servers can been found.
In the "Go-live" documentation stands that:
...
Production https://{server}.docusign.net/...
Note: {server} is the data center location of your production account (for example, NA1, NA2, or EU). You can obtain your production data center location from:
...
The admin account is located in EU. Does this mean that the production server will always be EU or it will also call the NA1, NA2 etc.?
From the following list will every server be part of the infrequent change?
https://na1.docusign.net
https://na2.docusign.net
https://na3.docusign.net
https://na4.docusign.net
https://eu.docusign.net
https://au.docusign.net
https://ca.docusign.net
Will be more servers in the future (EU1, EU2 etc.)?
Clarification:
I want to have a firewall rule to my server and I want to be 100% sure that every server will be accessible. What it is not clear to me, is the "Accounts move between base URIs infrequently" note. Does this apply to NA only (because only NA has more than one server)?
If you make the getUserInfo() call you will get the list of accounts and for each one - its baseURI that will tell you what it is.
There may be more in the future, yes, but there's no way to get that information at present time.
Related
So I have been using docusign developer account for performing in-person and remote signing using docusign APIs. I am interesting in knowing 2 things:
The developer account (with the base url account-d.docusign.com) seems to be working fine for me. Why can't I use it for production as well. What difference/advantage does the paid account(with API access) has? What changes exactly when the integration app that I am using for docusigning goes live from "demo", other than the base url (i.e., account.docusign.com)?
When I login to my account, and go to Settings > Integrations > Apps & Keys, I can see a value "baseUrl" under "API Username" and "API Account ID", this value is either "https://na3.docusign.net" or "https://demo.docusign.net". However, when I use either of these values in my code to perform in-person or remote signing, it gives error. I have to use url account-d.docusign.com, then the API calls work correctly. What is the use of baseUrl mentioned in the portal then? Does it change when the integration app goes live? In our old app we just changed the url in code from account-d.docusign.com to just account.docusign.com when app went live and it worked.
Production accounts are the only ones you can use for "real" i.e. valid signatures for legal purposes. Developer account (demo) is for developing, testing, showing what can be done to customers etc. You need to follow the Go-Live process to enable your integration in production.
the baseURL is for API calls, not for authentication. And like you indicated, it's different in each env. If your code already handles this - you don't need to worry about it, but this is not the URL for the web app, rather the URL to make API calls.
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.
I have a few questions regarding firebase storage?
I am generating download URLs for firebase storage objects using and admin account (has custom claims) and storing the URL on Firestore.
Users can read the Firestore document to get the URL instead of having to call getDownloadUrl on the client side code.
Q1) I noticed there is a token at the end of the storage URLs. Is this specific to my admin account and is it safe that none admin users can now read this token?
Q2) Furthermore if a non admin user called getDownloadUrl on the same storage path would they receive the same URL as the admin account or a different one?
Q3) If I switch to using getDownloadUrl on the client side would this increase my cost when using firebase storage?
Q4) If i am caching the content by URL and the URL changes it will redownload and not use cache.. Are these download links unique or can getDownloadURL return different URLs on subsequent calls?
Thanks a lot
Edit ---
Sorry I have an additional question
Q5)To move files on firebase storage I currently download them to my local pc and reupload them to another location -- seems very inefficient.
I have seem people using file.move() (as can be seen here.)
Would this be possible to call in a firebase function (as they talk storage rules being an issue in the comments, although its from 2016) and if so how would this be cheaper than my manual download and upload?
Sorry for many questions :)
Q1) I noticed there is a token at the end of the storage URLs. Is this specific to my admin account and is it safe that none admin users can now read this token?
This token is a a random ID generated for this specific file. It won't change, unless you change it intentionally (you can "revoke" the token from the Firebase Console, which will replace it with a new token). Everyone who possesses the URL can view the file whether they are authenticated or not. However, the URL is "hard to guess", so unless you share it with anyone, it will stay secret, practically speaking.
Q2) Furthermore if a non admin user called getDownloadUrl on the same storage path would they receive the same URL as the admin account or a different one?
The returned URL will always be the same, unless you invalidate it in the Firebase Console. If you don't want clients to call getDownloadURL on the files, add a Storage Security Rule that denies reads:
match /path/to/{file} {
allow read: if false;
// Or, if only authed users should be able to call getDownloadURL:
allow read: if request.auth != null;
}
Q3) If I switch to using getDownloadUrl on the client side would this increase my cost when using firebase storage?
A call to getDownloadUrl() does utilize some Google Cloud resources that you will have to pay for, whether you do it server-side or client-side. It's a "Class B" operation (check Google Cloud pricing), and a bit of data transfer.
Q4) If i am caching the content by URL and the URL changes it will redownload and not use cache.. Are these download links unique or can getDownloadURL return different URLs on subsequent calls?
The same URL is return each time, unless you manually invalidate the token. (By the way, the caching policy that sets the Cache-Control header is set on the object as metadata when you upload it.)
Q5) To move files on firebase storage I currently download them to my local pc and reupload them to another location -- seems very inefficient. [..] Would this be possible to call in a firebase function
Yes, you can move files in a Firebase Cloud Function. The Firebase Admin SDKs bypasses security rules.
1) I noticed there is a token at the end of the storage URLs. Is this specific to my admin account and is it safe that none admin users can now read this token?
Depends on what you have at the moment since you can integrate Custom Authentication with Firebase which will allow you to create custom tokens that can be used to sign into the Firebase Authentication service on a client application and assume the identity described by the token’s claim. This can be used when accessing other Firebase services, such as Cloud Storage, etc.
In general your server should create a custom token with a unique identifier.
2) Furthermore if a non admin user called getDownloadUrl on the same storage path would they receive the same URL as the admin account or a different one?
Depends on how you are setting the permissions for the getDownloadUrl. If you have a customized one they can receive a different one but usually it returns a new instance that points to the current reference.
3) If I switch to using getDownloadUrl on the client side would this increase my cost when using firebase storage?
I am not sure about this, I have checked the documentation and there is nothing that would indicate a quota or pricing on this specific method so I would go ahead and assume that it would not do it but I might be wrong on this one.
4) If i am caching the content by URL and the URL changes it will redownload and not use cache.. Are these download links unique or can getDownloadURL return different URLs on subsequent calls?
As specified before, it returns a new instance that points to the current reference so these download links are unique.
5) To move files on firebase storage I currently download them to my local pc and reupload them to another location -- seems very inefficient.
For this question and the last part of your initial post I would suggest you to create a support ticket and ask more details to the Firebase Support Team where you can get more information regarding this since it is more suited for them than to StackOverflow. (https://firebase.google.com/support)
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.
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.