Codestin Search App

vilmosnagy · 2024-09-24T20:48:08Z

Breaks only one test, RegisterTest::testRegisterShouldFailBeforeUserCreationWhenUserIsInContext, which was added in #23064 (issue #21514) - that test covers basically the same bug (also reported by me). In the previous bug the steps to reproduce was:

go to reset credentials, and pick a valid username
then go back, and try to register -> the fix was to check and raise an error during the registration if the user was set in the ResetCredentialChooseUser

The current issue (#33204) I'm having in short is:

go to reset credentials, and pick a valid username
then go back to the login page -> the social logins, which doesn't linked to the picked account, will be hidden from the login. You don't even need to pass the authentication to find out what social sites the user has linked to their account.

My current fix checks whether a user has been set in the context during an attempted (and cancelled) reset credential flow - and if it has been set, then we clear them from the context when loading the login page.

If I modify the failing test (also written by me), would you be willing to merge this? Probably I need to:

modify the failing test
add a new, slightly modified RegisterTest::testRegisterShouldFailBeforeUserCreationWhenUserIsInContext one where the login page is skipped entirely

cc @ahus1 @sguilhen @mposolda who was involved in the test which fails currently.

jonkoops · 2024-09-24T20:52:35Z

Thanks for the PR! FYI if you want to link an issue you can use a keyword to do so. We try to avoid mentioning the issue in the title. I went ahead and edited the issue description to link it up.

keycloak-github-bot

Unreported flaky test detected, please review

keycloak-github-bot · 2024-09-24T21:37:58Z

Unreported flaky test detected

If the flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR.

org.keycloak.testsuite.webauthn.registration.PolicyJsInjectionTest#relyingPartyId

Keycloak CI - WebAuthn IT (chrome)

java.lang.AssertionError: Expected RegisterPage but was Sign in to test (https://localhost:8543/auth/realms/test/protocol/openid-connect/auth?response_type=code&client_id=test-app&redirect_uri=https%3A%2F%2Flocalhost%3A8543%2Fauth%2Frealms%2Fmaster%2Fapp%2Fauth&state=a195fd75-3463-4ce5-a0e3-70c72425c0f4&scope=openid)
	at org.junit.Assert.fail(Assert.java:89)
	at org.junit.Assert.assertTrue(Assert.java:42)
	at org.keycloak.testsuite.pages.AbstractPage.assertCurrent(AbstractPage.java:47)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
...

Report flaky test

sguilhen · 2024-09-30T21:26:10Z

@vilmosnagy I haven't had the time to look into your PR yet, but the test failures seem to be related - actually only one test seems to be failing - a registration test.

EDIT: sorry, didn't read your description properly - I agree with your proposal to fix the test as described.

vilmosnagy · 2024-10-06T15:36:23Z

@sguilhen thanks for your feedback, I've pushed the changes I described. As far as I see the failing tests are not connected to this PR (they seem to be js & db related, while I only touched registration-flow related code).

Could you please move forward with the review? Thanks

sguilhen · 2024-10-06T19:29:28Z

@ahus1 Could you please re-run the CI for this PR? Failures don´t seem related to the changes

vilmosnagy · 2024-10-07T11:00:25Z

@sguilhen @ahus1 thanks for the retry. If I see correctly, currently only one test fails in the admin ui e2e tests. Am I correctly assuming that it has nothing to do with my modifications? What's your opinion on this?

Thanks,
Vilmos

sguilhen · 2024-10-07T11:41:33Z

@vilmosnagy @ahus1 Yeah, this test has been failing in other PRs, but IIRC it was fixed last week (see #33440). Have you rebased your branch recently?

ahus1 · 2024-10-07T11:46:54Z

Rebased just now, let's see what the tests report.

vilmosnagy · 2024-10-07T14:48:56Z

@sguilhen as far as I remember I've rebased it during the weekend. But it fails even after @ahus1 's rebase as well :'(

sguilhen · 2024-10-07T18:35:35Z

@edewit I thought this duplicate group test was disabled last week, but it seems it is still happening like in this PR. Any ideas what we could do?

edewit · 2024-10-08T07:49:36Z

@sguilhen I thought it was skipped as well, it seems it's not the case I've added a commit that disables this test to this PR

vilmosnagy · 2024-10-08T10:59:46Z

Is that possible that the failing test03SpnegoLoginWithCorrectKerberosPrincipalRealm test is a flaky one? It was detected by the bot in previous issues with a very similar stacktrace & error: #32283 (comment)

Signed-off-by: Vilmos Nagy <[email protected]>

…ehaviour Signed-off-by: Vilmos Nagy <[email protected]> # Please enter the commit message for your changes. Lines starting # with '#' will be kept; you may remove them yourself if you want to. # An empty message aborts the commit. # # Date: Sun Oct 6 16:35:19 2024 +0200 # # On branch issue_33204 # Changes to be committed: # modified: testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/forms/RegisterTest.java #

sguilhen · 2024-10-08T12:25:45Z

Is that possible that the failing test03SpnegoLoginWithCorrectKerberosPrincipalRealm test is a flaky one? It was detected by the bot in previous issues with a very similar stacktrace & error: #32283 (comment)

Yeah, it is likely a flaky one that needs to be looked into

mposolda

@vilmosnagy Thanks for the PR! I think that the change in the test RegisterTest.testRegisterShouldFailBeforeUserCreationWhenUserIsInContext is OK IMO.

However I have one more scenario I would like to discuss, when user opens link from the email after click "Back". In details:

User clicks "Forget password" on the login screen
User chooses the username john (Now john useris set in the authenticationSession) and there is email sent to the email address of john
Now user click "Back" and login screen is displayed
Now user goes to his email and clicks on the link from the email from step (2). Now what happens?

It seems to me that before this PR, user is verified and he is able to reset his password and then he is authenticated.

But can you check what happen after your changes?

I did not check, but I think that after your changes, the user is not verified as he is not anymore in the context of authenticationSession. IMO this change is fine if there is some sensible page displayed to the user like Action expired. Please continue here with the link where user can restart his login and continue from the start. But what is not OK is some unexpected error page like NullPointerException (I did not tried, but I have some suspicion that NPE can happen in AbstractActionTokenHandler.verifyEmail due the user cleared from auth session, but maybe I am wrong :-)

mposolda · 2024-10-10T10:59:56Z

...s/src/main/java/org/keycloak/authentication/authenticators/browser/UsernamePasswordForm.java


+    private void clearUserIfComingFromResetPassword(AuthenticationFlowContext context) {
+        if ("true".equals(context.getAuthenticationSession().getAuthNote(RESET_CREDENTIAL_USER_CHOSEN))) {
+            context.clearUser();


IMO it will be good to clear the RESET_CREDENTIAL_USER_CHOSEN note as well. Otherwise, during next invocation of this method, the user will be cleared again, which is not feasible.

An alternative and more generic approach might be to move this from UsernamePasswordForm somewhere to the upper layer (AuthenticationProcessor or DefaultAuthenticationFlow) and reset whole authenticationSession (something like AuthenticationPRocessor.resetFlow) when it is detected that flow was changed from reset-credentials back to the browser . However I am not sure if it is easily and reliably possible to detect this?

vilmosnagy · 2024-10-10T11:22:37Z

Hi @mposolda,

Thanks for your review.

But can you check what happens after your changes?

You're probably right—my changes might break the forgot password flow if the user navigates back to the login page before clicking on the email link.

One question, though: do we need to show an action expired page in this case? For example, if I start the password reset flow on one device (e.g., mobile) and click the reset password link on another (e.g., desktop), the reset is allowed in the new session. The only difference is:

If the user opens the link in the original session, they are redirected back to the app in a logged-in state.
If the user opens the link in a new session, an informational page is displayed with a prompt to return to the base URL of the client.

Would this approach be feasible for you? Just theorizing here, but maybe something like:

The user clicks "Forgot password" on the login screen.
The user enters the username john (now john is set in the authentication session), and an email is sent to john's email address.
The user clicks "Back," and the login screen is displayed.
The user clicks the link in the email from step 2.
John is allowed to set the new password and is redirected to client.baseUrl upon success - the same way they'd be redirected if they'd opened the link in a new browser session.

Either way: I see your points here, and I'll need a couple of days to write a few more tests. I'll get back to you once those are done.

Thanks again,
Vilmos

mposolda · 2024-10-11T07:23:37Z

@vilmosnagy Yes, I think you are right. It will be better user experience if the user is authenticated similarly like in the current Keycloak main instead of displaying Action expired page.

The only thing is, in the described scenario, the user might not be anymore in the context of authenticationSession after your changes. So perhaps in that case, it may be OK to add user back to the authenticationSession based on the info from the actionToken? I can see that VerifyEmailActionToken has reference to the user, so hopefully it should be possible to restore the user in the authenticationSession.

Anyway, it will be good to add automated test for this scenario and make sure that it works as expected.

Thanks a lot for the discussion and for the additional work on handling those cases!

mposolda · 2024-12-16T14:35:44Z

@vilmosnagy Any chance to continue on this PR?

vilmosnagy · 2024-12-19T19:12:13Z

Sorry for the disappearance @mposolda - a newborn just arrived to my household in the past few weeks, and I had a few things to finish at my workplace before that.

I'll try to finish this PR by the beginning of the new year - if I won't come back and push my changes to this PR by the 6th of January, then probably I won't be able to finish this in the next months.

thomasdarimont · 2024-12-19T20:41:52Z

@vilmosnagy congratulations :)

mposolda · 2025-03-31T17:29:13Z

@vilmosnagy Sure, take your time. Keeping this PR opened for now. Congratulations! :-)

mposolda · 2026-02-10T12:14:19Z

Closing for now as PR is in the queue for very long time.
@vilmosnagy Feel free to re-open (or open new PR) once you have time. Anyone else is also welcome to eventually open the PR and continue with the work (in that case, please add the reference to this PR in the new PR).

vilmosnagy requested review from a team as code owners September 24, 2024 20:48

keycloak-github-bot bot added team/cloud-native team/core-clients team/core-iam labels Sep 24, 2024

jonkoops changed the title ~~fix #33204 - Identity provider should not be hidden from login page when the a user goes back from the reset credentials page~~ Identity provider should not be hidden from login page when the a user goes back from the reset credentials page Sep 24, 2024

vilmosnagy force-pushed the issue_33204 branch from cb87194 to b962b95 Compare September 24, 2024 20:52

keycloak-github-bot bot added the flaky-test label Sep 24, 2024

keycloak-github-bot bot reviewed Sep 24, 2024

View reviewed changes

vilmosnagy force-pushed the issue_33204 branch 2 times, most recently from 1cd5ec9 to 50b425a Compare October 6, 2024 14:39

This was referenced Oct 7, 2024

Flaky test: org.keycloak.testsuite.broker.KcOidcBrokerTest#testPostBrokerLoginFlowWithOTP_bruteForceEnabled #33549

Closed

Flaky test: org.keycloak.testsuite.forms.BrowserButtonsTest#appInitiatedRegistrationWithBackButton #32676

Closed

ahus1 force-pushed the issue_33204 branch from 50b425a to 4299e30 Compare October 7, 2024 11:46

keycloak-github-bot bot mentioned this pull request Oct 7, 2024

Flaky test: org.keycloak.testsuite.forms.LevelOfAssuranceFlowTest#testWithOTPAndRecoveryCodesAtLevel2 #33505

Closed

edewit requested a review from a team as a code owner October 8, 2024 07:48

keycloak-github-bot bot added the team/ui label Oct 8, 2024

jonkoops force-pushed the issue_33204 branch from 3e908b4 to bbde983 Compare October 8, 2024 10:10

vilmosnagy added 3 commits October 8, 2024 13:24

keycloak#33204 add the failing test

a7bdcc1

Signed-off-by: Vilmos Nagy <[email protected]>

keycloak#33204 possible fix (?)

a49f2d8

Signed-off-by: Vilmos Nagy <[email protected]>

vilmosnagy force-pushed the issue_33204 branch from bbde983 to c8fd722 Compare October 8, 2024 11:24

mposolda self-assigned this Oct 8, 2024

mposolda reviewed Oct 10, 2024

View reviewed changes

mposolda closed this Feb 10, 2026

Conversation

vilmosnagy commented Sep 24, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jonkoops commented Sep 24, 2024

Uh oh!

keycloak-github-bot bot left a comment

Choose a reason for hiding this comment

Uh oh!

keycloak-github-bot bot commented Sep 24, 2024

Unreported flaky test detected

org.keycloak.testsuite.webauthn.registration.PolicyJsInjectionTest#relyingPartyId

Uh oh!

sguilhen commented Sep 30, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vilmosnagy commented Oct 6, 2024

Uh oh!

sguilhen commented Oct 6, 2024

Uh oh!

vilmosnagy commented Oct 7, 2024

Uh oh!

sguilhen commented Oct 7, 2024

Uh oh!

ahus1 commented Oct 7, 2024

Uh oh!

vilmosnagy commented Oct 7, 2024

Uh oh!

sguilhen commented Oct 7, 2024

Uh oh!

edewit commented Oct 8, 2024

Uh oh!

vilmosnagy commented Oct 8, 2024

Uh oh!

sguilhen commented Oct 8, 2024

Uh oh!

mposolda left a comment

Choose a reason for hiding this comment

Uh oh!

mposolda Oct 10, 2024

Choose a reason for hiding this comment

Uh oh!

vilmosnagy commented Oct 10, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mposolda commented Oct 11, 2024

Uh oh!

mposolda commented Dec 16, 2024

Uh oh!

vilmosnagy commented Dec 19, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

thomasdarimont commented Dec 19, 2024

Uh oh!

mposolda commented Mar 31, 2025

Uh oh!

mposolda commented Feb 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

vilmosnagy commented Sep 24, 2024 •

edited

Loading

sguilhen commented Sep 30, 2024 •

edited

Loading

vilmosnagy commented Oct 10, 2024 •

edited

Loading

vilmosnagy commented Dec 19, 2024 •

edited

Loading