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"
}
Related
I am using the DocuSign REST API to send documents and we are trying to take advantage of the webhook capabilities.
Our problem is that we have basic auth set up on our webhook listener which it doesn't appear is supported in the REST API. I am enquiring whether or not this is an accurate understanding. I know it is possible on the Connect product, which the basic auth can be set up via the portal, however I am looking specifically for API REST calls.
How can I secure the EventNotification event?
Many thanks,
Mitch.
As of now, according to docusign offical post:
Individual Envelope Connect configurations created with the eventNotifications API option do not support Basic Authentication at this time.
A WORKAROUND SOLUTION:
Docusign has an official blog post to answer this question. Securing Your Connect Webhook Listener
For us, we use the Use a Pre-shared Secret method to secure our webhook. We are using the python sdk. During the process we create the EventNotification, we add a secret parameter to the webhook listener url. When the docusign post the request to your listener server, it will include the secret. You could check the parameter to make sure the request is valid.
event_notification = EventNotification()
event_notification.url ='your webhook_url' + '?secret=' + 'your_secret')
The text below is quoted from the blog post.
This defense acts both as access control and authentication. The
listener URL you provide to DocuSign can include one or more query
parameters. DocuSign will include them during its POST request to your
listener.
For access control, your listener will first check that the request
includes the expected query parameter and reject all requests that
don’t. For authentication, your listener will additionally check the
value of the query parameter. Remember that you can encode any values
for the name and value of the query parameter. For this example, we’re
using “pw” as the name of the query parameter.
To use a pre-shared secret, just set the URL accordingly in the
Connect configuration. For example,
https://listener_url.example.com/listener?pw=secret
Remember that the complete URL, including its query parameters, is
encrypted before it is sent across the internet. The URL and its query
parameters are visible in various logs and configuration screens,
including the Connect webhook configuration page.
I have been experimenting with the REST API using my logged in user account's token to then make PUT requests on my user record to update some custom attributes.
In order to get to this work I had to grant my user account the manage-users role in Keycloak, prior to this I was getting forbidden responses back.
I can now make the PUT request successfully, and after logging out and logging back in I can see the updated attributes I set in my PUT request.
But I have now allowed my user to be able to manage all users in my realm, which I dont want to allow.
Instead I only want to be able to update my own account details.
I know the user can view their own profile and make changes on the Keycloak provided screens. But for certain custom attributes I want to be able to do this from the client side application they are logged in to, so using the REST API but not granting them a role that could allow them to update other users details.
Is this possible?
According to the User section Keycloak's Admin REST API, this is not possible.
One solution would be for your client app to send the update request to a backend. The backend will verify that the update request is legit (aka the JWT is verified and the update does apply to the user requesting the change).
Another solution would be to theme the User Account Service's screens to add input fields for your custom attributes, as the documentation says that:
This screen can be extended to allow the user to manage additional attributes. See the Server Developer Guide for more details.
The second option seems the more secure. I hope that helps.
This seems to be possible with the Account Management API.
Unfortunately, I didn't find any official documentation about that. However, there's an example in Keycloak that demonstrates how to do it.
I have went through https://developers.callfire.com/docs.htm and cannot find any endpoint or webhook which retrieves the form values entered by the agent while on call. Kindly assist.
I assume you are working on IVR scenarios? If this is the case, then you are looking for Advanced section of IVRs, allowing you to make HTTP requests to your service with input gathered during the call: https://www.callfire.com/help/docs/advanced-tab-buttons#section2
I am trying to get the list of all users with their email addresses from a confluence cloud instance using their REST API. There is nothing in their documentation regarding users. Also the email address is never embedded in any of the response containing user objects. Is there a way to retrieve email address of the user based on the username.
You will have to use their older APIs -- the methods are there.
I'm doing a GET for customers with a given email address (there will only be one). Before displaying the returned information, I need to authenticate the user, but I can't see a way in the docs that allows providing a password as a parameter to a GET. In fact It only seems to be possible to provide a password when creating (POSTing) or updating (PUTting) a customer. Is it possible to authenticate customers via the API this way?
from what I understand - _authentication is only supported for POST and PUT on customer objects. I believe it is intended to create a customer who can login and stuff like that.
Can you explain your use case and maybe there is a workaround..