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 compatibility with league/oauth2-server:^9 #186

Merged
merged 1 commit into from
Aug 16, 2024

Conversation

ajgarlag
Copy link
Contributor

No description provided.

@wmouwen
Copy link
Contributor

wmouwen commented Jun 24, 2024

Would love to see this PR to be released when stable! 🚀

@chalasr
Copy link
Member

chalasr commented Jul 20, 2024

@ajgarlag would you appreciate some help finishing this? thanks for the PR!

@ajgarlag
Copy link
Contributor Author

@ajgarlag would you appreciate some help finishing this? thanks for the PR!

@chalasr Sure! Any help is welcome!

I think that there is a supported use case that we should deprecate: calling the authorization controller without any authenticated user (in other PR). WDYT?

@ajgarlag ajgarlag marked this pull request as ready for review July 20, 2024 18:08
@chalasr
Copy link
Member

chalasr commented Aug 12, 2024

I think that there is a supported use case that we should deprecate: calling the authorization controller without any authenticated user (in other PR). WDYT?

I agree. We should also disallow passing null to UserConverterInterface::toLeague() isn't it?

@chalasr
Copy link
Member

chalasr commented Aug 12, 2024

Sure! Any help is welcome!

Is there anything missing actually? I just see WIP in the title but this looks good

@ajgarlag
Copy link
Contributor Author

Sure! Any help is welcome!

Is there anything missing actually? I just see WIP in the title but this looks good

My main concern is with the last commit, but I think this will affect only a minimal number of users.

@ajgarlag
Copy link
Contributor Author

I think that there is a supported use case that we should deprecate: calling the authorization controller without any authenticated user (in other PR). WDYT?

I agree. We should also disallow passing null to UserConverterInterface::toLeague() isn't it?

I would merge this PR and disallow passing null to UserConverterInterface::toLeague() in a new PR before tagging a new version. WDYT?

Does Symfony allow an empty string as a user identifier?

@chalasr chalasr changed the title [WIP] Add compatibility with league/oauth2-server:^9 Add compatibility with league/oauth2-server:^9 Aug 12, 2024
@chalasr
Copy link
Member

chalasr commented Aug 12, 2024

I would merge this PR and disallow passing null to UserConverterInterface::toLeague() in a new PR before tagging a new version. WDYT?

Works for me 👍

Does Symfony allow an empty string as a user identifier?

No, built-in authenticators forbid it https://github.com/symfony/symfony/blob/dd9fa153d344593c7fe12eb761158558377d98a4/src/Symfony/Component/Security/Http/Authenticator/JsonLoginAuthenticator.php#L149

@@ -31,6 +32,11 @@ public function getConfigTreeBuilder(): TreeBuilder
->defaultValue('ROLE_OAUTH2_')
->cannotBeEmpty()
->end()
->scalarNode('anonymous_user_identifier')
Copy link
Member

Choose a reason for hiding this comment

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

Can you please remind me under which flow do we expect anonymous users? Wording-wise the anonymous concept has been removed in Symfony but I feel like this one is different and specific to this bundle, what's the case I'm missing?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The AuthorizationController does not require authentication (although it is highly recommended), so when the AuthorizationRequestResolveEvent is dispatched, there is a valid use case where the AuthorizationRequestUserResolvingListener cannot set the user instance in the event:

public function onAuthorizationRequest(AuthorizationRequestResolveEvent $event): void
{
$user = $this->security->getUser();
if ($user instanceof UserInterface) {
$event->setUser($user);
}
}

So the $event->getUser() call can return null with a resolved authorization

$authRequest->setUser($this->userConverter->toLeague($event->getUser()));

This is the use case I think we should disallow.

@ajgarlag
Copy link
Contributor Author

I would merge this PR and disallow passing null to UserConverterInterface::toLeague() in a new PR before tagging a new version. WDYT?

Works for me 👍

Does Symfony allow an empty string as a user identifier?

No, built-in authenticators forbid it https://github.com/symfony/symfony/blob/dd9fa153d344593c7fe12eb761158558377d98a4/src/Symfony/Component/Security/Http/Authenticator/JsonLoginAuthenticator.php#L149

But the interface allows it. Maybe a /** @return non-empty-string */ annotation should be added to the UserInterface. I'll submit a PR to deprecate this behavior in Symfony 7

@ajgarlag
Copy link
Contributor Author

But the interface allows it. Maybe a /** @return non-empty-string */ annotation should be added to the UserInterface. I'll submit a PR to deprecate this behavior in Symfony 7

See symfony/symfony#58007

$accessToken = new AccessTokenEntity();
$accessToken->setClient($clientEntity);
$accessToken->setUserIdentifier($userIdentifier);
if (null !== $userIdentifier && '' !== $userIdentifier) {
$accessToken->setUserIdentifier($userIdentifier);
Copy link
Member

Choose a reason for hiding this comment

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

Given the low potential of breaking people's code as you said + the fact we're still in 0.x version (not for long I think!), I'm fine doing this change although it's a bit aggressive.

@chalasr
Copy link
Member

chalasr commented Aug 16, 2024

Thank you @ajgarlag.

@chalasr chalasr merged commit 978087a into thephpleague:master Aug 16, 2024
20 of 21 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants