Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue #5442 - add MultiAuthenticator to support multiple authentication options #12393

Open
wants to merge 7 commits into
base: jetty-12.1.x
Choose a base branch
from

Conversation

lachlan-roberts
Copy link
Contributor

Issue #5442

Introduces the MultiAuthenticator class which can be used to support multiple authentication options simultaneously for the same webapp.

For example you could have an app with the options to login with FORM, OpenID or Ethereum.

@lachlan-roberts lachlan-roberts self-assigned this Oct 16, 2024
Signed-off-by: Lachlan Roberts <[email protected]>
@lachlan-roberts lachlan-roberts requested a review from gregw October 30, 2024 13:18
if (session == null)
return false;

synchronized (session)
Copy link
Contributor

Choose a reason for hiding this comment

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

This is unnecessary, following the discussion on #10392.

I'd remove all the synchronized blocks around the session, as I understand from @janbartel that it is going to be a different instance for every request in any case, so synchronization is useless.

Copy link
Contributor

Choose a reason for hiding this comment

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

@sbordet that's not what I said. I said iff you use the NullSessionCache, every request will have their own copy of the session. This is not true for the DefaultSessionCache, which - as the name implies - is the default situation. If you're doing authentication, then you shouldn't be using the NullSessionCache, and the documentation makes abundantly clear that if you are writing to the session in any way, then you should not use it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

And so the authenticators should still synchronize on the session when neccessary.

assertThat(response.getContentAsString(), containsString("<h1>Multi Login Page</h1>"));
assertThat(response.getContentAsString(), containsString("/login/openid"));
assertThat(response.getContentAsString(), containsString("/login/form"));
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I would like to see:

  • for this test, the access to a protected resource should be tried for both authentications.
  • a new test for failed authentication, protected resources are not accessible
  • a test where one authentication succeeds but the other fails -- can I still access the resource? Basically I would like to know if "multi" has "and" semantic (all authentications but must successful), or "or" semantic (one successful authentication is enough).

@joakime joakime linked an issue Jan 15, 2025 that may be closed by this pull request
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 👀 In review
Development

Successfully merging this pull request may close these issues.

Allow multiple authentication options for a web app
4 participants