Migration of testsuite's OAuthClient
by Stan Silvert
This PR includes the migration of OAuthClient from the old testsuite to
the new arquillian-based testsuite:
https://github.com/keycloak/keycloak/pull/2485
There was already another class named OAuthClient in
org.keycloak.testsuite.util. So to avoid confusion, this one is named
org.keycloak.testsuite.MigratedOAuthClient.
Except for the name, MigratedOAuthClient is identical to the one in the
old testsuite. So it should work with migrated tests. I've already
used it in several of these tests.
There is one slight difference in the way it obtains the baseUrl. I
have migrated the Constants class and renamed it to MigratedConstants.
Instead of the url being hard-coded as in the old testsuite, this url is
obtained through a call to
AuthServerTestEnricher.getAuthServerContextRoot().
Stan
10 years, 1 month
Expected behaviour for rememberMe?
by Marek Posolda
Followup on the issue by Libor [1] . I can confirm to see the same
behaviour in the OOTB Keycloak, like Libor described in the JIRA. In
other words, when you refresh account page (
http://localhost:8080/auth/realms/myrealm/account ) but the UserSession
referenced from KEYCLOAK_IDENTITY cookie is expired, then all cookies
including KEYCLOAK_REMEMBERME are expired too.
IMO RememberMe cookie shouldn't be expired when session is expired.
We're using the rememberMe cookie as hint for username on the login
page. So even if user returns to page after a month, I am not seeing
anything bad that rememberMe cookie is still valid and user will see
"hint" with his username on login page and rememberMe checkbox checked
even if session was expired already for a long time. IMO the only
situation when we should expire KEYCLOAK_REMEMBERME cookie is, when user
unchecks the "Remember me" checkbox on login page.
[1] https://issues.jboss.org/browse/ORG-2956
Marek
10 years, 1 month
AbstractUsernameFormAuthenticator validateUserAndPassword process
by Ariel Carrera
Hi, I am developing a Federation Provider, and I have a question...
Why the method () checks if the user "is enabled" after validate the
password instead of before of the password validation?
AbstractUsernameFormAuthenticator.validateUserAndPassword: line 141/151
...
if (invalidUser(context, user)){
return false;
}
* if (!validatePassword(context, user, inputData)){*
* return false;*
* }*
* if(!enabledUser(context, user)){*
* return false;*
* }*
...
If the user is disabled... why validate his password and return a password
validation error message?
--
Ariel Carrera
10 years, 1 month
