8000 Improve session polling to prevent accidental redirects by jonkoops · Pull Request #35143 · keycloak/keycloak · GitHub
[go: up one dir, main page]

Skip to content

Improve session polling to prevent accidental redirects - #35143

Merged
mposolda merged 1 commit into
keycloak:mainfrom
jonkoops:fix-session-polling
Nov 28, 2024
Merged

mposolda merged 1 commit into
keycloak:mainfrom
jonkoops:fix-session-polling

Conversation

@jonkoops
Copy link
Copy Markdown
Contributor

Improves the session polling in the login flow used to detect user sign-ins from other contexts (e.g. another tab or window). This fixes an issue where a user experiences a redirect to another page when submitting the login form, causing an unexpected re-start authentication error.

This change also cleans up the code a little by renaming some functions to be more appropriate with their purpose, as well as adding additional comments to explain various parts of the code.

Closes #33071

edewit
edewit previously approved these changes Nov 20, 2024
@jonkoops
Copy link
Copy Markdown
Contributor Author

Putting this on hold until we're able to test that this indeed fixes the issue, please do not merge until this label is removed.

@rmartinc rmartinc left a comment
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jonkoops! Works OK to me! Let's see what @t-tani says when testing in his env...

@mposolda mposolda self-assigned this Nov 22, 2024
mposolda
mposolda previously approved these changes Nov 22, 2024
@jonkoops
Copy link
Copy Markdown
Contributor Author

As far as the team can tell this fix should work for the reported issue, we intend to merge this in next week Monday if there are no objections.

@t-tani
t-tani commented Nov 27, 2024 •
Copy link
Copy Markdown

@jonkoops I'm sorry for my late response.
I tested your PR with my environment with the following setup:

  • Server: Keycloak 26.0.5
  • Proxy: BurpProxyPro (intercepting authChecker.js and rewriting to the PR authChecker.js)
  • Client: iPhone 14 Pro (iOS 18.0.1 / Safari)
  • OpenIDC Client: Cloudflare

Tested Authentication Methods and Results

  • Password: OK
  • OTP: OK
  • Passkey: NG

The issue persists only in the case of Passkey authentication. Upon inspecting the HTML, I found that the "Sign in with Passkey" button does not use a form submission during authentication. As a result, the session polling event is not properly stopped.

Here is the relevant HTML structure for Passkey authentication:

<div class="pf-v5-c-form__group no-bottom-margin">
    <form id="authn_select" class="pf-v5-c-form">
        <input type="hidden" name="authn_use_chk" value="<redacted>"/>
        <input type="hidden" name="authn_use_chk" value="<redacted>"/>
        <input type="hidden" name="authn_use_chk" value="<redacted>"/>
    </form>

    <div id="kc-form-buttons" class="col-xs-12 col-sm-12 col-md-12 col-lg-12">
        <input id="authenticateWebAuthnButton" type="button" autofocus="autofocus"
               value="Sign in with Passkey"
               class="pf-v5-c-button pf-v5-c-button pf-m-primary pf-m-block btn-lg"/>
    </div>
</div>

To resolve the issue in my environment, I added the following code to the proposed implementation, which attaches a stopSessionPolling() event to all input[type="button"] elements:

const buttonInputs = document.querySelectorAll('input[type="button"]');

buttonInputs.forEach((input) =>
  input.addEventListener("click", () => stopSessionPolling())
);

While I have not thoroughly tested the impact of attaching stopSessionPolling() to all input[type="button"] elements on other functionalities, this change successfully resolved the Passkey issue in iOS browsers during my testing.

Closes keycloak#33071

Signed-off-by: Jon Koops <jonkoops@gmail.com>
@jonkoops
jonkoops dismissed stale reviews from mposolda and edewit via cb5d7cf November 27, 2024 17:07
@jonkoops
jonkoops force-pushed the fix-session-polling branch from 2afbfab to cb5d7cf Compare November 27, 2024 17:07
@jonkoops
Copy link
Copy Markdown
Contributor Author

@t-tani thank you so much for doing this detailed testing, it really helps us out! The reason why the form submission was not working is because we're calling .submit() from JavaScript in various places, which does not send out a submit event:

This method is similar, but not identical to, activating a form's submit <button>. When invoking this method directly, however:

The HTMLFormElement.requestSubmit() method is identical to activating a form's submit <button> and does not have these differences.

I went ahead an replaced all instances where .submit() was called with .requestSubmit(), and this seems to resolve the issue you encountered as the submit event is now triggered. Could you take another look to validate this?

@t-tani
t-tani commented Nov 27, 2024
Copy link
Copy Markdown

@jonkoops
Thank you for the clarification! That makes perfect sense, and I appreciate the insight—very informative.

I tested the updated implementation, in which .submit() is replaced with .requestSubmit() with my environment. All authentication methods, including Passkey, work correctly on the iOS browser without any accidental redirects after authentication.

Thank you very much for the fix and your efforts!

@jonkoops
Copy link
Copy Markdown
Contributor Author

Great to hear! I'll make sure to get this merged and backported ASAP. Thanks again for all your assistance!

@jonkoops jonkoops removed the status/hold PR should not be merged. On hold for later. label Nov 27, 2024
@mposolda
mposolda merged commit 687223f into keycloak:main Nov 28, 2024
@jonkoops
jonkoops deleted the fix-session-polling branch November 28, 2024 11:24
@jonkoops
Copy link
Copy Markdown
Contributor Author

Backport for v26 is up under #35408

@FlxPeters
Copy link
Copy Markdown

@mposolda The change from submit() to requestSubmit() unfortunately introduces a breaking change for some clients.
The Microsoft Office 365 desktop clients have an embedded Edge 18 Browser, which does not support the method.
Due to this, the login it works as expected, but breaks the MFA selector form which prevents a successful login on these clients. This was partially fixed in #35659, but only for the SAML post form.

I would like to suggest rolling this back to the submit() method, where it's not a hard dependency.
It was pretty hard to find the root cause of this issue since it's not a specific change and more a side effect. If you're fine with this suggestion, I can provide an MR.

Side note: We also try to open a case at Microsoft to evaluate why they ship such an old embedded browser.

@rmartinc
rmartinc commented Mar 31, 2025 •
Copy link
Copy Markdown
Contributor

@FlxPeters You can always create a custom theme for those old clients changing the method.

@FlxPeters
Copy link
Copy Markdown

@rmartinc Sure, and we have to for now. My point is that this should be a dedicated change and not a side effect of another one. No bad feelings at all, such things happen. I opened an MR for the rollback: #38558

@rmartinc
Copy link
Copy Markdown
Contributor

@FlxPeters If you rollback the change then the issue #33071 is again in place. Which is for iphone users. So or we have issues in one place or in another, the only real fix would be separating by browsers that we are don't want to do. Somebody should have to change themes. IMHO it should be the one not supporting the new standards. But let's see what people think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

RESTART_AUTHENTICATION_ERROR in Iphone devices (using safari and chrome browser)

7 participants

0