As mentioned on the link https://developers.docusign.com/esign-rest-api/guides/authentication/oauth2-code-grant, there are three access scopes DocuSign allows to fetch user's data : signature, extended and impersonation.
I am looking for a scope which allows me only read access. I need to build a dashboard of various activities/updates (getting the status of all envelopes, etc) of all the users of DocuSign at my company.
As per my understanding, I need 'signature' permissions/scope at-least as described under heading "Admin consent for internal applications" on https://developers.docusign.com/esign-rest-api/guides/authentication/obtaining-consent.
This means I will have access to create and delete the envelopes as well. Couldn't understand the 'extended' scope as well (as per my reading, it is helping to extend the access tokens validity and usage of refresh token any number of times).
Is their any other permission type (read scope only) that I can use based on my criteria?
Re read only scope. Not at this time. And since you want stats for all users' envelopes, you'll need Account Wide Rights. Full Admin is not necessary.
Perhaps an alternative might be to use the connect webhook system, and then track statistics as your app receives each notification message about changes to the users' envelopes.
Related
I know that we could use Auth Code Grant, implicit grant or JWT grant. But I have the following scenario:
I have my own app. All users are usually logging in to my app, so I use JWT grant. But sometimes the contract should be assigned from a future employee, who does not have any account yet. Therefore I want to use Authenticaion Code Grant (send him a link via email and he authenticate and assign on DocuSign).
Is is possible to use two different authentication methods for two different recipients in one document/evelope?
I tested each one separelty and works. But both of them in one app?
Yes it is technically possible, but I'm not certain that's the best way to go about this. If you want to generate an OAuth token for a specific user they're required to have their own DocuSign account as they need to provide documented consent for whatever scopes you're requesting.
But to answer your question, an OAuth token gives access to any account that the authenticated user has access to. Once the tokens themselves are generated there isn't any rule or blocker that would prevent you from creating a token for a secondary user and then alternating between the two, as long as the token is used to auth against an account that it has access to. It becomes a little more difficult to keep track of the multiple tokens and corresponding userId -- but you can absolutely do that.
If you want to have one of these envelopes signed by a user that doesn't have an account yet -- I would agree with Inbar that embedded signing would be the correct way to go. Embedded signers aren't required to have their own accounts -- however in order to generate a recipientViewToken you need to authenticate as the sending user. On the customer side what they would see is a one-time-use URL that has a default lifetime of 6 minutes. This URL is typically loaded into a browser tab or some sort of modal window which then takes them directly into the signing session.
If you don't want to use embedded signing and would rather use the email link, you can still do that. Unless you're using a CFR 21 part 11 account users can still sign documents without an account -- they'll just be prompted to sign up for one afterwards so there's somewhere to house the envelope. I think based on this it would be better to use the embedded model, but we can support you on either path.
We are using the CalendarView endpoint to retrieve a users appointments for a specific time period. While calling the endpoint we are passing $select=start,end,showAs to only retrieve the fields that we are interested in.
Our end client is concerned that even though we are filtering the results on our side we still have access to Calendars.Read and technically have access to read meeting subjects, etc. Is there any way in Office365 or the Graph API that our end client can apply more granular permissions to filter which fields we have access to?
Today Microsoft Graph application permissions give your application full access to the entity they cover (all the properties)/the endpoint (all the payload).
There's is no way to restrict access to specific properties of an entity for a specific application.
You can always suggest this idea on uservoice.
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.
I'm making an app that authenticates a coach with KA's API, in order to present statistics and reports on the progress of each student.
How do I see "For whom am I a coach" (inverse of /api/v1/user.coaches)?
or otherwise request user and progress data for all my students?
You can request /api/v1/user/students to get a list of the currently authenticated users' students. Note that this is an undocumented endpoint, not sure if that's on purpose or not, but I suspect just an oversight because IIRC I've seen them reference it on github issues in the past.
I added that endpoint to the khan npm module in this PR: https://github.com/weo-edu/khan/pull/4
An important caveat to note is that as of this writing, you won't be able to request students on behalf of a user who has authenticated your application, only the user who created the app you're currently using.
Put another way: If I create an application called "hello" while logged in as "Jeffrey", I can get all of Jeffrey's students by authenticating with the "hello" app. However, If I log in as Lisa via the "hello" app (via oauth, e.g. passport-khan), I'll have an access token but the Khan API will refuse my request because Lisa did not create the "hello" app.
This behavior is documented (albeit a bit confusingly) in this wiki page, here's the relevant paragraph:
It is recommended that schools have one teacher/coach account that registers for an API key. This enables a situation where the logged-in user is the same as the third-party developer, who then can access their own students' data pursuant to Khan Academy's "coach" relationship. For example, suppose the principal of Riverdale High wished to export data for multiple students via the API. The principal would create a teacher/coach account, perhaps called "RiverdaleHighAPI," and register for an API key. The principal would then ask all students of Riverdale High to add "RiverdaleHighAPI" as a coach, either directly or via several class codes. When accessing the API with "RiverdaleHighAPI" as the logged in user, the principal would be able to access the data for all students that have added "RiverdaleHighAPI" as a coach. The app would not have access to any other coaches' student data, even if another coach logged in through the app. To protect student privacy, we do not allow indirect consent through the coach, and we require each student to explicitly grant permission to access their data. Please note that we are working to improve this functionality; for the time being, this "RiverdaleHighAPI" account should only be used by the school's API client, not by any actual teacher or coach.
Lastly, khan actually encourages public use of their internal API. They recommend opening up your developer console while logged in to khan and looking for the endpoints that return the data you want. (see this note on their authentication document).
This is obviously a fairly non-standard practice and I assume the endpoints would be subject to breaking changes without warning. Also you'll be flying documentation free. That said, this approach may be the most robust option for your purposes. Here's the quote from their wiki for posterity:
The API explorer documents our public API, which has URLs starting with /api/v1, but unfortunately it's not very well-maintained and lacking in a few areas.
If you're feeling adventurous, though, you're welcome to use any internal undocumented API endpoints. For example, if you load a Khan Academy video page and use your browser's developer tools to look at the ajax requests being sent, you'll see that it gets a URL like /api/internal/videos/aubZU0iWtgI/transcript, which contains a JSON response with the video subtitles. That "internal" in the name means that we don't provide documentation, and we may remove the endpoint or change the format in the future, but you're welcome to use any internal endpoints if you keep those caveats in mind.
How can you get user-initiated access to read their email? It seems there is OpenID, OAuth, OAuth2 and random other solutions.
The best I came up with so far is OAuth2 with scope=https://mail.google.com/.
Is there any permission that would just give me read-only access to the mail and ideally not scare the user with a permission notice like:
"View and manage your mail
Perform these operations when I'm not using the application"
All I'd like, if possible "View your mail".
The previous answer is no longer accurate. The recently released Gmail API allows a 'read only' scope, among others, which can be found here: https://developers.google.com/gmail/api/auth/scopes.
The 'read only' scope is: https://www.googleapis.com/auth/gmail.readonly
https://www.googleapis.com/auth/gmail.readonly
Read all resources and their metadata—no write operations.
https://www.googleapis.com/auth/gmail.compose
Create, read, update, and delete drafts. Send messages and drafts.
https://www.googleapis.com/auth/gmail.send
Send messages only. No read or modify privileges on mailbox.
https://www.googleapis.com/auth/gmail.insert
Insert and import messages only.
https://www.googleapis.com/auth/gmail.labels
Create, read, update, and delete labels only.
https://www.googleapis.com/auth/gmail.modify
All read/write operations except immediate, permanent deletion of threads and messages, bypassing Trash.
https://www.googleapis.com/auth/gmail.metadata
Read resources metadata including labels, history records, and email message headers, but not the message body or attachments.
https://www.googleapis.com/auth/gmail.settings.basic
Manage basic mail settings.
https://www.googleapis.com/auth/gmail.settings.sharing
Manage sensitive mail settings, including forwarding rules and aliases.
Note: Operations guarded by this scope are restricted to administrative use only. They are only available to G Suite customers using a service account with domain-wide delegation.
https://mail.google.com/
Full access to the account, including permanent deletion of threads and messages. This scope should only be requested if your application needs to immediately and permanently delete threads and messages, bypassing Trash; all other actions can be performed with less permissive scopes.
The GMail API documentation says there is only one scope giving access to everything.
There is also a feature called GMail Inbox Feed which could be what you want, but it is only available on Google Apps domains.