-
Notifications
You must be signed in to change notification settings - Fork 129
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
Add Imperative AuthenticationProvider and Reactive AuthenticationProvider #1526
Conversation
@sdelamo It won't let me actually request you as reviewer since you started the PR. This is ready for review, but a few things to consider right off the top: As you will see, I realized one caveat of this approach to adapting the Also, I've only provided the Java implementation of the example in the docs - that's all we have for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As you will see, I realized one caveat of this approach to adapting the BlockingAuthenticationProvider implementations via @EachBean is that it requires the addition of a qualifier to each implementation if providing more than one. I don't love that, but do you think providing multiple implementations would be common enough to warrant a different approach?
I think it is fine to require a Name qualifier. I have changed the BlockingAuthenticationProvider
to extend io.micronaut.core.naming.Named
and the docs show now the example.
Also, I've only provided the Java implementation of the example in the docs - that's all we have for AuthenticationProvider as well. I'm thinking we should go ahead and provide Groovy and Kotlin versions of both as usual - I'll look at that first thing tomorrow.
Yes, we should provide kotlin and groovy examples always even if previous snippet of the docs did not. I have provided Groovy and Kotlin tests.
* BlockingAuthenticationProvider implements Named * split docs * add multilanguage snippet * remove import * revert use class again
...rc/main/java/io/micronaut/security/authentication/BlockingAuthenticationProviderFactory.java
Outdated
Show resolved
Hide resolved
…ockingAuthenticationProviderFactory.java
*/ | ||
@Factory | ||
@Internal | ||
class BlockingAuthenticationProviderFactory { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we not call it blocking? It doesn't need to block
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have changed the API ImperativeAuthenticationProvider
.
If the user implementation is blocking he should add the @Blocking
annotation to the overridden method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the plan? Rename it in v5? Or keep it like this forever?
IMHO I would create a new API non-reactive AuthenticationProvider
and ReactiveAuthenticationProvider
in a different package and deprecate the old one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we were starting from zero, I would not be against the naming to be ReactiveAuthenticationProvider
for the publisher api and AuthenticationProvider
for the imperative API.
But we already have an API in place, which most users will have implemented in their applications and I am not keen to forcing them to change their code for a better name.
Having the same API name in different packages sounds tricky to me as well.
I don't think having two APIs: the existing AuthenticationProvider
which is reactive and a new ImperativeAuthenticationProvider
which is not reactive is too bad.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dstepanov I have deprecated
io.micronaut.security.authentication.AuthenticationProvider
and created two APIs:
- Imperative =>
io.micronaut.security.authentication.provider.AuthenticationProvider
- Reactive =>
io.micronaut.security.authentication.provider.ReactiveAuthenticationProvider
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sdelamo I like this - it's clean and more consistent with the terminology we use elsewhere (i.e., Micronaut Data).
|
||
@Override | ||
public Publisher<AuthenticationResponse> authenticate(T httpRequest, AuthenticationRequest<?, ?> authenticationRequest) { | ||
return Mono.fromCallable(() -> blockingAuthenticationProvider.authenticate(httpRequest, authenticationRequest)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would expect to use the new API directly in the filter, not have it wrapped in a reactive
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Preferable this change should allow not engage any reactive filtering when all the filters are non-reactive
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that should be attempted in the next major version of Micronaut Security.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have removed the factory and now I only create a ReactiveAuthenticationProvider
if users define any other ReactiveAuthenticationProvider
or if the user authentication provider is blocking c795eaa
Only create ReactiveAuthenticationProvider from imperative if there is any ReactiveAuthenticationProvider or if there is a blocking imperative AuthenticationProvider
...aut/security/oauth2/endpoint/token/request/password/OauthPasswordAuthenticationProvider.java
Outdated
Show resolved
Hide resolved
…point/token/request/password/OauthPasswordAuthenticationProvider.java
@jeremyg484 can you review? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, just have some nit picking suggestions for JavaDocs.
security/src/main/java/io/micronaut/security/authentication/AuthenticationProvider.java
Outdated
Show resolved
Hide resolved
security/src/main/java/io/micronaut/security/authentication/Authenticator.java
Outdated
Show resolved
Hide resolved
.../main/java/io/micronaut/security/authentication/provider/ReactiveAuthenticationProvider.java
Outdated
Show resolved
Hide resolved
…thenticationProvider.java Co-authored-by: Jeremy Grelle <[email protected]>
…ovider/ReactiveAuthenticationProvider.java Co-authored-by: Jeremy Grelle <[email protected]>
…thenticator.java Co-authored-by: Jeremy Grelle <[email protected]>
.../main/java/io/micronaut/security/authentication/provider/ReactiveAuthenticationProvider.java
Outdated
Show resolved
Hide resolved
.../main/java/io/micronaut/security/authentication/provider/ReactiveAuthenticationProvider.java
Outdated
Show resolved
Hide resolved
...rity/src/main/java/io/micronaut/security/authentication/provider/AuthenticationProvider.java
Outdated
Show resolved
Hide resolved
...c/main/java/io/micronaut/security/authentication/provider/AuthenticationProviderAdapter.java
Outdated
Show resolved
Hide resolved
...src/main/java/io/micronaut/security/authentication/provider/AuthenticationProviderUtils.java
Outdated
Show resolved
Hide resolved
...in/java/io/micronaut/security/authentication/provider/HttpRequestAuthenticationProvider.java
Outdated
Show resolved
Hide resolved
...io/micronaut/security/authentication/provider/HttpRequestReactiveAuthenticationProvider.java
Outdated
Show resolved
Hide resolved
security/src/main/java/io/micronaut/security/authentication/Authenticator.java
Outdated
Show resolved
Hide resolved
… private This commits moves AuthenticationProviderUtils and AuthenticationProviderAdapter package private to make io.micronaut.security.authentication. AuthenticationProviderUtils and AuthenticationProviderAdapter package private.
Quality Gate passedKudos, no new issues were introduced! 0 New issues |
Close #1476