I'm attempting to resend an envelope to recipients but get "This user lacks sufficient permissions to access this resource." The envelope was sent by our api user on behalf of another user which is also in the account. So the initial envelope creation would have looked like:
X-DocuSign-Authentication: <n:DocuSignCredentials xmlns:n="http://www.docusign.com/restapi"><IntegratorKey>MY-KEY</IntegratorKey><Password>password</Password><Username>api-user#here.there</Username><SendOnBehalfOf>other.user#somwhere.else</SendOnBehalfOf></n:DocuSignCredentials>
...
That succeeded and I can pull up the envelope audit events via the rest api. However, attempting to resend the envelope using the existing recipients as is as the same api-user results in:
<errorDetails>
<errorCode>USER_LACKS_PERMISSIONS</errorCode>
<message>This user lacks sufficient permissions to access this resource.</message>
</errorDetails>
Any ideas?
It turns out my error was in not specifying the same SendOnBehalfOf user when attempting the resend. Adding that in allows things to work as expected. Same for voiding an envelope and presumably any other envelope altering operation.
Related
I'm currently trying to use Microsoft Graph to send a Microsoft Teams Chat message to a specific employee.
The idea behind that is that I want to be able to send chat messages using PowerShell, but for now, I'd be happy to get it done in Microsoft Graph first and build a PowerShell script afterward.
Important: I don't want to post a message to a Channel, only in a 1:1 chat.
What I've tried:
I'm able to get the current chats for my own user by using:
https://graph.microsoft.com/beta/users/{myid}/chats
If, however, I try that with a different user's id, I get a 401 (permission denied) error. I can't even see their current chats even though I have all available permissions.
In the error message, it says the following:
"User Id must match the API caller when called in delegated mode"
... but I don't want to use delegated mode since that'd mean I'm executing the commands as if I would be that user, and therefore couldn't create the chat message which I want in the first place.
It might sound rather confusing, so I hope you get what I mean.
To my knowledge, there's no way to send a message directly to the user without some kind of context. The problem becomes, for instance, where would the message appear, and who would it be from?
If you could deal with it being inside a Channel instead, then PowerShell is fine as you can set up a webhook to do this. I've done the same, from PS -> Teams a few years ago, so I assume it should still work. This article should help.
Alternatively, if you really want a "1-1" conversation, so to speak, you need to create and register a Bot, so that the message comes "from someone" to the user. This concept is called Pro-active Messaging and I've posted more about it here. However, coming purely from PowerShell it's going to be a LOT of work:
Create a Bot in Azure to get the App ID and Password. Technically this would be a non-existent Bot as there's no implementation, which means if the user were to reply it would go nowhere. This might be ok? You could possibly try build an Azure Function Bot in PowerShell, but not something I've done myself so can't advise (I've only used C# for Bots thus far)
Create a Conversation ID, and save it for later - again, a bunch of work.
Convert the code (e.g. from my post above) into PowerShell, referencing the relevant NuGet packages.
So, I'd recommend trying to find an approach using a Teams Channel rather, and messaging the user there, if you can manage that in your use case?
Unless all of this is irrelevant if you're trying to send on behalf of another user?
The term "Delegated" in this context refers to the type of permissions claims included in the OAuth token. There are two types; Application and Delegated.
There are two key rules when it comes to Application vs. Delegated scopes:
A single token may only contain a single type of scope. In other words, the token itself is either an Application or Delegated token, never a combination of the two.
The type of scopes applied to a Token is determined by the OAuth Grant you used to obtain it:
Authorization Code: Delegated
Implicit: Delegated
Client Credentials: Application
With regard to the List Chats (/chats) endpoint, only Delegated permissions are supported:
Delegated (work or school account): Chat.Read, Chat.ReadWrite
Delegated (personal Microsoft account): Not supported.
Application: Not supported.
There is a general rule of thumb when it comes to permissions in Microsoft Graph (I use 'general' here since there are a couple of exceptions in older endpoints): Delegated scopes that only apply to the current user end in Read or ReadWrite while those that apply to any user end in .All.
Since these two scopes (Chat.Read and Chat.ReadWrite) do not end in .All, and only Delegated scopes are supported, this tells you that the only Chats you are able to access are those owned by the currently authenticated User. In other words, you cannot read another User's chat messages via the API.
If you think about it, this makes a lot of sense. If you didn't have an authenticated User, who would the Chat message you sent be "from"? A chat message requires both a Sender and a Recipient.
For your scenario, there are a couple of possible workarounds from a Teams ChatBot to simply setting up a new User that you authenticate as and send messages to other Users from.
I am trying to change account email in Keycloak, but did not find any useful information in the Keycloak official documentation.
I tried work with this endpoint
PUT /admin/realms/{realm}/users/{id}/execute-actions-email
but it only accepts an array of actions and sends to a user an email to perform specified actions.
But I want to update it directly performing my request. Is this possible?
I think you are looking for below API.
PUT /admin/realms/{realm}/users/{id}
with a JSON payload as below.
{
"email":"new#email.com"
}
For a POST request in my Restful API I want to record requests from certain users for audit purposes. I know who the users are in these cases so I can ask them to include their email address in the request. Since this is really metadata for the request, the From request header seems a natural place to require the email to be sent. However, I can't remember anyone ever actually using this header.
Would it feel strange to other developers to see the From header being used in a modern application?
RFC 7231
The From header field is rarely sent by non-robotic user agents. A user agent SHOULD NOT send a From header field without explicit configuration by the user, since that might conflict with the user's privacy interests or their site's security policy.
A server SHOULD NOT use the From header field for access control or authentication, since most recipients will assume that the field value is public information.
My interpretation is that the From header is there to allow the client to volunteer information, not so that the server can require it. For your situation, where you control the clients, using the header is fine, but given that your intent is to "record requests from certain users for audit purposes" I would expect the Authorization header to be more appropriate.
I have created an envelope, added recipients and documents to the envelope through REST API call in apex code. Now I want to view my envelope in docusign user interface before ot it sent to the signers. Can I connect to the docusign from REST API call in apex and view the envelope?
There are different type of views you can use, based on the Envelope status, details are available at https://docs.docusign.com/esign/restapi/Envelopes/EnvelopeViews/ You might be interested in seeing https://docs.docusign.com/esign/restapi/Envelopes/EnvelopeViews/createCorrect/ or https://docs.docusign.com/esign/restapi/Envelopes/EnvelopeViews/createEdit/ or if sender wants to see it then https://docs.docusign.com/esign/restapi/Envelopes/EnvelopeViews/createSender/
You can use the EnvelopeViews: createSender API (also called Embedded Sending) to open the "tag and send" view of the envelope and let your users send it through the DocuSign Console. This also allows them to make changes to envelope before sending, given that they have the correct permissions.
This is what the API request typically looks like:
POST /v2/accounts/{accountId}/envelopes/{envelopeId}/views/sender
{
"returnUrl": "https://your.app.com/callback"
}
Once the user is done sending the envelope they will be redirected to the URL that's provided in the returnUrl parameter.
I'm trying to enroll a user with a REST method. The user exists, and I'm using as endpoint /d2l/api/lp/1.0/enrollments/
The params and sign params are right, because I was able to create the user, and perform other calls.
But the only response I'm getting for that call is
[Status=See other, StatusCode=303]
And nothing else, like the URL to redirect.
Has somebody been through this already? Or any hints of what I could be doing wrong?
Thanks.
Notice that the rights to enroll are granted based on a matrix of permissions (RoleType,OrgUnitType). That is, your calling user may be able to create a user record and enroll that user as a Student Role in the Organization org unit type, and not have the permissions to enroll that user in a Department, Semester, Course Offering, or other org unit type.
The 303 you're getting is most likely a redirect to an error page as a result of your POST failing for some reason. If you're able to make other calls fine, then the most likely errors are that your calling user context is not permitted to make the enrollment action you're trying, you're not identifying the user, user role, or org unit properly in the CreateEnrollmentData block you're passing, or the block is malformed in some way.
It may help to further diagnose the issue if you use Fiddler, WireShark, or some other packet sniffer utility to closely examine the exact HTTP request you're making, and the exact response traffic you're getting back as a result. For more assistance there, you can look at this blog article on D2L's Developer Blog.