I know there's an earlier question with this subject here, but the OP never reported if the one answer resolved the issue. And since
Internal Server Error
is about as user-unfriendly as you can get, I would love to change this to something that feels more like "a message" than "an anvil dropped on your foot".
I have found one other SO post that tangentially relates to this issue (about that disappearing "duplicate emails" switch), but the problem is indeed not about whether or not to allow duplicate emails (or how to revive hidden admin controls) but how a very ordinary issue is communicated to the user - well, like how Keycloak notifies the user when they try and register with an existing username.
We're currently using the Docker version of Keycloak 12.0.4 with some customisations (a custom BCrypt module, some logging changes) running in IBM Cloud, using a Postgresql DB. We also added a custom theme & internationalisation. The same error occurs also when using the default Keycloak theme, though.
Here are our Login settings:
It turned out to be a configuration issue, but so deeply hidden that even the Keycloak developer who looked into the ticket I created had glossed over it.
The perpetrator was in menu Configure > Authentication > tab: Flows > choose dropdown: Registration > Profile validation radio button [o REQUIRED | o DISABLED]
This was set to disabled, which in effect prevents the duplicate email check in the registration form that the Realm settings > tab: Login form suggest are active. But then, of course, the database won't like that, with above-mentioned result.
This combination of settings should at least issue a warning, of course. I hope this will be corrected.
Related
I'm currently troubleshooting a login issue for a deployed Moodle. Login page uses an alternate page which I have managed to identify. The alternate page considers everything except successful login as invalid or expired login or password.
Since some correct login and password are also getting the same issue.I am trying to restore the Moodle instance to use its default login page but did not find any $CFG->alternateloginurl configuration set in moodle.php. Kindly please provide any pointers you can think of on where to look next to restore the login page.
PS: I've also searched within the active theme, and there has not been any code changes. Uses a variant of Moove
Thank you
Rest assured that its a common issue
https://docs.moodle.org/401/en/Managing_authentication#Alternate_login_URL
There is an entry in the database
SELECT *
FROM mdl_config
WHERE name = 'alternateloginurl'
Note the value, just in case, then blank it out
UPDATE mdl_config
SET value = ''
WHERE name = 'alternateloginurl'
Then purge the cache to update Moodle
php admin/cli/purge_caches.php
When you do manage to log in, check which other authentication methods are active via
Site administration > Plugins > Authentication > Manage authentication
https://docs.moodle.org/401/en/Managing_authentication
The default methods are manual and email self registration
Although self registration is disabled by default in the settings on the same page (registerauth)
I have keycloak on docker (v20.0.2) and as you know some versions change some or good part of the UI, so is hard to follow tutorials around the web...
I am trying to follow this particular tuto
https://developers.redhat.com/blog/2020/11/24/authentication-and-authorization-using-the-keycloak-rest-api#keycloak_sso_demo
that seems the more updated. My keycloak is actually behind traeffic and thomseddon/traeffic-fordward-auth with a docker-compose file (but the connection through traeffic is good and I have acces to admin UI)
So on step 10 of the tutorial things change for me, I have to look for that particular view inside:
Click on lateral menu Client Scope
Click on button Create client scope
Give a name to the scope, and click on Tab Mapper
All mappers are predefined... so there is no "New mapper" don't understand this bit
then just follow the tuto
With that series of steps I get an error when retriving the token...
https://keycloak:8443/realms/education/protocol/openid-connect/token
enter image description here
(this are fake local data from the realm I created for testing)
that responds with a or something similar I have also tried to change the grant_type to password, and the same happens can not query the token....
{
"error": "invalid_client",
"error_description": "Invalid client or Invalid client credentials"
}
But if I do not link a user with an scope/role as in the tuto suggest then I get the token, but of course I want to use the role or scope to limit who can see which endpoint and who can not
Any step that I'm missing from this update, do you have the same error?
Thank you in advance
I have tried to run it with different combinations of options to see if there is a toggle that actually allows me to fetch the token
Also with different types of grant_type
I will build an API in Python (I don't know Java and prefer Json instead of XML) that connect to this keycloak to allow users or not based on their scope/role/permission or something
I need to be able to block user so if user Student try to access an url from another Student he get blocked that url. So is based on the role or scope or I don't know which is prefered or easer to accomplish, the mission is to block users or not based on a factor that could be used for this in keycloak.
In Keycloak, by default, users are able to change their first and last name in the account manager page. However, is it possible to disable this behavior?
Removing both fields in the theme results in those values not being sent and the form failing, and a hand-crafted POST request would defeat this method anyway.
I came across a similar problem and after reading this SO post, came to know that although you can disable/hide fields in ftl, you cannot disable form validation
For e.g I hid firstname field , but still cannot submit. Same was the result with disable as well:
I am not aware about disabling a particular field in some other way. However there is a workaround in which you can disable the entire account modification flow (Password can still be changed by Forgot Password option).
Bu default, account modification is enabled, but you can disable it for a particular realm by going to Realms -> Clients -> Account.
The result of this will be, the account page will be inaccessible:
You can remove the client role 'manage_account' for client 'account'.
In Keycloak, by default, users are able to change their first and last
name in the account manager page. Is it possible to disable this
behavior?
That can be done out-of-the-box (since Keycloak 14) by using the user profile functionality. First, the preview feature declarative-user-profile has to be enabled. For that start the server with:
--features=declarative-user-profile.
for the Quarkus version, or with
-Dkeycloak.profile.feature.declarative_user_profile=enabled
for the Wildfly version.
Bear in mind that:
Declarative User Profile is Technology Preview and is not fully
supported.
After starting the server with the aforementioned option, go to the Keycloak Admin Console and:
Go to the according Realm;
Go to the tab General;
Set User Profile enabled to ON
A new tab named User Profile (top right) will show up; click on it, and a set of configurable attributes will be shown.
Click on firstName, and then go to Permissions
In that section the permissions can be changed, accordingly. For example, if one sets Can user edit? to OFF, then when the user tries to change the firstName field in the account UI, that UI throws the following warning message:
The field First name is read only.
The same configuration can also be applied to the lastName attribute.
For the new Keycloak UI the workflow is exactly the same as the one I have just described. More information about the feature can be found in the official keycloak documentation (link)
You can use readonly property to disable email you can just change the following line:
<input type="text" class="form-control" id="email" name="email" readonly autofocus value="${(account.email!'')}"/>
In Keycloak/Red Hat SSO 7.0, the base theme ships with a message bundle including accountTemporarilyDisabledMessage.
In the login theme, how do I detect that Keycloak has thrown the AuthenticationFlowError.USER_TEMPORARILY_DISABLED exception so that I can display this message rather than continuing to inaccurately report "Invalid username/password" (the default behavior)?
Keycloak/Red Hat SSO user Freemarker Templates to render their UI pages. So essentially I just need the name of the hook to reference in the login.ftl but there are no examples of this I can find.
Like #kiml42 in the known duplicate below, I'm trying to avoid having to make rest service calls to a server that is already being exposed by the Freemarker system they have set up.
Known duplicate question:
Keycloak: Indicate user is temporarily locked
Related Issues:
https://issues.jboss.org/browse/KEYCLOAK-4036
https://github.com/keycloak/keycloak/pull/3972/files/d1343ed8489c7635ad820687667f6bc38d8dfa54
I'm new to Fiddler and have run across something that seems strange to me. If I select an entry and then click Replay, I get different behavior from when I drag an entry into the Composer window and click Execute.
Should the different behavior between these two methods of re-making a request be different?
Note: I called the second method "cloning" a request because the Composer window says "You can clone a prior request by dragging and dropping a session from the Web Sessions list)."
What is the "different behavior" specifically?
The two operations you describe should behave the same way unless the server returns a redirect or an authentication challenge, in which case preferences will control whether Fiddler automatically authenticates and/or follows the redirect.
Please feel free to email me (Help > Send Feedback) details and/or screenshots of the difference you see.