By default, our users does not have email. But we want to allow users to set / update their emails from account management console.
We have noticed the following issue. When the user does not have an email already set, the email field is not visible from "Personal Info" tab of account management console.
However if we set an email from admin console -> realm -> users, the email field is visible and editable for the user from account management console.
before setting an email for the user (email is null)
after setting an email for the user (without changing any other settings)
Does this mean that users cannot set an email if their email is not already set?
Is there any way we can allow users to set an email themselves?
Note that we don't want to force a user to set their email. It is optional.
If we assign "Update Profile" as a Required user action for user, they are shown our custom theme profile update UI. currently we are manually assigning "Update Profile" Required user action upon request from the user which is not ideal.
We also haven't modified the account management console theme.
Keycloak version: 20.0.1
We have tried switching different options from "Realm Settings" -> "Login" tab. doesn't work
Expecting users to be able to set an email from account management console even when they don't already have an email set
Related
We have a PHP/MySQL based User Management System and are integrating it with Keycloak version 16 where we will store users credentials.
Our application does not allow users to self register. We create user accounts on the system. When we do this we do NOT specify a password because we want users to set up their own password.
The current system sends 2 separate emails in 2 different circumstances regarding passwords:
If it's a completely new user who does NOT have an existing password, we send them a link to set up a password.
If it's an existing user who already has a password, the system allows them to reset it, e.g. if they forget their password and can't login.
Keycloak seems to cater for scenario (2) because the login forms have a forgotten password link which opens a form where the user can enter their email address and receive a link which lets them do (2).
Unfortunately it doesn't deal with scenario (1) very well and that's where our problem starts. This has been asked a while ago Send password forgotten mail but it seems that Keycloak didn't support this very well in 2020 and perhaps still doesn't now.
Our "workaround" to this was that we added custom email templates and a custom page (reference: Themes on https://www.keycloak.org/docs/latest/server_development/#emails) which includes wording that caters for both scenarios, e.g. "set your password" rather than "reset your (existing) password". The result of this is that our email and form now reads appropriately for both scenarios (1) and (2).
The problem
We want to be able to send a link to the user that allows them to set their initial password to cover scenario (1).
We know that this page exists because on the login page for Keycloak there is a link to the forgotten password form that handles scenario (2). However, the form requires the user to enter their email address and submit the form. The user then receives an email from Keycloak which contains a URL to the page where they can do this. The URL has the following format:
https://example.com/auth/realms/foo/login-actions/action-token?key=...
The key= contains a ~945 character token. Going to the URL above redirects to the form where the user can reset their password. This next URL does not contain a token but a cookie has been set in the browser - by the previous URL - which makes it functional:
https://example.com/auth/realms/foo/login-actions/required-action?execution=UPDATE_PASSWORD
We can't send either of these URLs to the user because the first one (containing key=) has no API method for us to find out what it is - it's only possible to generate this by going through the "forgotten password" step during login, in the browser.
The second URL (/login-actions/required-action...) won't work either because it relies on the previous URL (containing key=) setting the cookie in the browser. If you try and go to this second URL directly (i.e. bypassing the first URL) it will error.
So neither of these URLs will work because we can't find what the first one is programmatically, and we can't use the second one without knowing the first one.
I found https://lists.jboss.org/pipermail/keycloak-user/2018-October/015910.html and the suggestion is using the Keycloak API to trigger a password reset email. This works - sending an HTTP PUT request containing 'UPDATE_PASSWORD' along with the relevant user ID sends the user an email. The request endpoint has the format PUT /{realm}/users/{id}/execute-actions-email which is documented on the link above.
Up to here all is fine - the user gets an email. However, this email does NOT contain a link that goes directly to the "reset password" page! Instead it sends them an email containing the following text:
Your administrator has just requested that you update your account by performing the following action(s): Update Password. Click on the link below to start this process.
Link to account update
When the user clicks "Link to account update" it then shows them a web page like this:
It is only when they click on the link on this page (the one that says "click here to proceed" on the screenshot) that they arrive at the form where they can reset their password.
This is a really poor user experience because the user gets sent a (badly worded) email with a link to... a page with another link! It should just take them to the password reset page directly. What's more frustrating is the fact that Keycloak is clearly capable of generating/sending the exact email we'd like in this scenario: the one which gets sent when a user manually does a password reset via their browser.
So the problem seems that Keycloak's API doesn't support this incredibly important and common use-case of a user being able to set an initial password, in a user-friendly manner.
I am adding the js script in the template to automatically click "click here to proceed". It's ugly but at least the user doesn't see the page
I have some issue with User Account Settings. (Drupal 8)
Normaly there is a possibility to change the content on every mail...but it's does not work.
If an user register to my website (from a front form) a different email is send than the one i configure here:
enter image description here
Someone ?
The Welcome (new user created by administrator) email template (as its label says) is for accounts created by admin, not for users who manually register on your site.
The email template your users are receiving is Welcome (awaiting approval) or Welcome (no approval required), depending on whether administrator approval is required or not.
I am gsuit user, I have created many user accounts from my admin account of gsuit, i want to make one of the user account as a no-reply account,
i.e. when someone sends reply on that account it should automatically get rejected with reject message.
From your G Suite account go to Apps > G Suite > Gmail > Advanced Settings.
Choose the organizational unit to affect, I would recommend to have this users specifically on an organizational unit since by making this change it will affect all of the users within that OU.
After selecting the OU look for the option "Routing" within that option there is another one called the same "Routing"
Click on the "Configure" button.
A popup will appear
For "Messages to affect" select "Inbound"
For "For the above types of messages, do the following" select "Reject message"
In Google Admin (formerly Google Suite) navigate to:
Apps > Google Workspace > Settings for Gmail > Default Routing
Link: https://admin.google.com/ac/apps/gmail/defaultrouting
Add a new rule
(1.) Enter email address: no-reply#domain.com
(2.) Change "Accept message" to "Decline message"
(2.) You can optionally enter a decline message
(3.) Change to "Execute this action for recognized and unrecognized addresses"
Send a test e-mail to this address to see if it works
You should receive a reply Delivery Status Notification (Failure) after a few minutes
We have Google Identity Toolkit implemented on our server and can successfully create "simple password accounts" and "Facebook accounts".
However if a user has first signed in with "simple password account", created password, confirmed email, etc...
How can this user then at a later time add Facebook as an alternative provider?
In our case, if this user clicks "Sign in" he will see:
On the following login screen however, he can only choose the existing "simple password account".. if he does, the login proceeds to password input, without a chance to use Facebook as an alternative.
What do we have to configure so that the user has the possibility at any time to link another provider to his "simple password account"?
Scroll down to the Account Linking section in this doc.
The key phrase here is Thus if Google Identity Toolkit detects that the same email address was used at both identity providers, we link the two accounts. It appears this is not something you can do manually, and accounts can only be linked in this particular situation. In the case of Facebook I believe the email to which they are referring would be the primary email found in the Facebook user settings.
I hope they implement more comprehensive account linking in the future! The Gitkit account manager would be the ideal place to do this if you are listing Google.
I need to find out if a customer (during checkout) is also currently logged in as a Zen Cart administrator. The purpose is for allowing certain actions to be available for an administrator placing an order on behalf of a customer (say, by telephone).
My first idea was to check $_SESSION['admin_id'].
However this does not seem to be set, instead $_SESSION['customer_id'] is.
I think this is because different session names are chosen in the admin and customer areas (zenAdminId vs zenid).
How can I find out if this customer would be logged in as an admin, had they been in the admin area at the same time?
I am working on the checkout step prior to sending off to a hosted payment service provider.
Edit: the merchant is logged in as an admin and is entering the customer's details, which are different to those of the admin account, into the checkout screens. It is a customer-not-present/MOTO setup.
You are correct - $_SESSION['customer_id'] is set. And there's nothing in the customer's table which indicates if this person is an admin. However, if they use the same email address for their customer account and for their admin account, you can look up their email in the customers table with $_SESSION['customer_id'], then match that against the admin_email field in the emails in Use this to look up table "admin."
It is worth noting that if your admin cookie isn't restricted by path SESSION_USE_ROOT_COOKIE_PATH=True that you can simply check for the cookie zenAdminID. You can read the contents of this cookie by querying zen_sessions, the sesskey being the value in zenAdminID.
You have to base64_decode the value from the result to get the session. It gives a serialised object, although unfortunately you are unable to use unserialize on it. You can load it as the current $_SESSION but this would overwrite your current one.
I simply did this to get the admin_id:
preg_match('/admin_id\|s:1:"([0-9]+?)"/', $admin_session, $admin_matches);
$admin_matches[1] giving the admin id value.