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

Add Imperative AuthenticationProvider and Reactive AuthenticationProvider #1526

Merged
merged 40 commits into from
Jan 4, 2024

Conversation

sdelamo
Copy link
Contributor

@sdelamo sdelamo commented Dec 7, 2023

Close #1476

@sdelamo sdelamo linked an issue Dec 7, 2023 that may be closed by this pull request
@jeremyg484 jeremyg484 marked this pull request as ready for review December 12, 2023 00:00
@jeremyg484
Copy link
Contributor

@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 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?

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.

Copy link
Contributor Author

@sdelamo sdelamo left a 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
@sdelamo sdelamo requested a review from dstepanov December 12, 2023 19:07
@sdelamo sdelamo added the type: enhancement New feature or request label Dec 12, 2023
*/
@Factory
@Internal
class BlockingAuthenticationProviderFactory {
Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

@sdelamo sdelamo Dec 13, 2023

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

c795eaa

Copy link
Contributor

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))
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 expect to use the new API directly in the filter, not have it wrapped in a reactive

Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor Author

@sdelamo sdelamo Dec 13, 2023

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

@sdelamo sdelamo requested a review from dstepanov December 13, 2023 11:50
@sdelamo sdelamo changed the title add BlockingAuthenticationProvider Add Imperative AuthenticationProvider and Reactive AuthenticationProvider Dec 13, 2023
Only create ReactiveAuthenticationProvider from imperative if there is any ReactiveAuthenticationProvider or if there is a blocking imperative AuthenticationProvider
@sdelamo
Copy link
Contributor Author

sdelamo commented Dec 13, 2023

@jeremyg484 can you review?

Copy link
Contributor

@jeremyg484 jeremyg484 left a 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.

sdelamo and others added 3 commits December 14, 2023 06:38
…thenticationProvider.java

Co-authored-by: Jeremy Grelle <[email protected]>
…ovider/ReactiveAuthenticationProvider.java

Co-authored-by: Jeremy Grelle <[email protected]>
@sdelamo sdelamo requested a review from jeremyg484 December 14, 2023 05:38
… private

This commits moves AuthenticationProviderUtils and AuthenticationProviderAdapter package private  to  make io.micronaut.security.authentication. AuthenticationProviderUtils and AuthenticationProviderAdapter package private.
Copy link

sonarqubecloud bot commented Dec 14, 2023

@sdelamo sdelamo merged commit 14f234a into master Jan 4, 2024
15 checks passed
@sdelamo sdelamo deleted the blocking-authentication-provider branch January 4, 2024 21:13
@sdelamo sdelamo mentioned this pull request Jan 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement New feature or request
Projects
No open projects
Status: Done
Development

Successfully merging this pull request may close these issues.

add non reactive API for AuthenticationProvider
4 participants