-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Security] Make security.providers optional #26787
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
Conversation
Very complex topic, looks like you like them :) (#24805) @weaverryan and me have this in mind for a while, the issue is that actually pretty much all security listeners are requiring a user provider for user loading/refreshment. |
Yes the way we'll authenticate our users makes me discover some edge cases!
I don't understand how this is an issue? |
@@ -166,8 +166,7 @@ public function testPerListenerProvider() | |||
} | |||
|
|||
/** | |||
* @expectedException \Symfony\Component\Config\Definition\Exception\InvalidConfigurationException | |||
* @expectedExceptionMessage Not configuring explicitly the provider for the "http_basic" listener on "ambiguous" firewall is ambiguous as there is more than one registered provider. | |||
* @expectedException \TypeError |
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.
getting a TypeError
when not setting the provider isn't fine to me as this aims to make it optional
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.
Yes I agree we need a proper error but I don't know when to throw it.
I created a dummy user provider whose sole purpose is to throw an exception, WDYT? |
Huh, a dummy provider is a really clever idea - it makes this very feasible (and sure, we could try to rip out the guts of the user provider system later... but that will be super hard and will probably never happen). I like this! |
Do we need a functional test where authentication is done without user provider? |
@MatTheCat The config test added here should be enough |
Are we good to go then or are some things missing? |
Is it alright to let |
throw new InvalidConfigurationException(sprintf( | ||
'"%s" firewall requires a user provider but none was defined.', | ||
$firewall | ||
)); |
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.
small thing: should be on one line.
$container->setDefinition( | ||
$userProvider, | ||
(new ChildDefinition('security.user.provider.missing'))->replaceArgument(0, $id) | ||
); |
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.
CS fix: should be on one line.
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.
Oh okay.
/** | ||
* @param string $firewall the firewall missing a provider | ||
*/ | ||
public function __construct($firewall) |
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.
string typehint
Thank you @MatTheCat. |
This PR was squashed before being merged into the 4.1-dev branch (closes #26787). Discussion ---------- [Security] Make security.providers optional | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #21998 | License | MIT Don't really know if it's viable but I just hit #21998 so I would like to tackle this. Commits ------- ee54bfa [Security] Make security.providers optional
Don't really know if it's viable but I just hit #21998 so I would like to tackle this.