-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Security] Allow passing null as $filter in LdapUserProvider to get the default filter #27850
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
louhde
commented
Jul 5, 2018
Q | A |
---|---|
Branch? | master |
Bug fix? | no |
New feature? | yes |
BC breaks? | no |
Deprecations? | no |
Tests pass? | yes |
Fixed tickets | - |
License | MIT |
Doc PR | - |
{ | ||
if (null === $filter) { | ||
$filter = '({uid_key}={username})'; | ||
} |
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.
Is it still useful to have the default value in the argument list at this point? It's defined twice now with 2 different ways of making it a default value. I think the default value in the argument list can be removed. If I understand the need correctly, it's because you want to pass the $passwordAttribute
while the $filter
remains default, but it's an issue to write it out without constant?
…he default filter
@@ -35,12 +35,16 @@ class LdapUserProvider implements UserProviderInterface | |||
private $defaultSearch; | |||
private $passwordAttribute; | |||
|
|||
public function __construct(LdapInterface $ldap, string $baseDn, string $searchDn = null, string $searchPassword = null, array $defaultRoles = array(), ?string $uidKey = 'sAMAccountName', string $filter = '({uid_key}={username})', string $passwordAttribute = null) | |||
public function __construct(LdapInterface $ldap, string $baseDn, string $searchDn = null, string $searchPassword = null, array $defaultRoles = array(), string $uidKey = null, string $filter = null, string $passwordAttribute = null) |
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'm not sure what the collective opinion in the Symfony community is about this:
args(string $uidKey = null, string $filter = null)
But in theory it has to be written like:
args(string $uidKey = null, string $filter = null)
null is not an allowed type according to your signature, but it's listed as default value. In order to allow null to be a valid type, the signature should be:
args(?string $uidKey = null, ?string $filter = null)
With this signature you allow null to be present. Sadly php accepts both due to 7.0 not having nullable types.
I'm not sure if this should be fixed, what do you think @nicolas-grekas? Ideally I'd like to see this fix being applied on the whole codebase.
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.
We're maintaining a codebase that has branches that should run on PHP 5.5.
Updating to using ?
for nullable types would mean create merge conflicts we'll have to deal with for the next 3 years as mergers. Better not. Then, for consistency, we should not use it either for new code added to 4.x. The rationale is exactly the same as the one that makes us stick to array()
vs []
.
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.
It's the same for PHP, but I tend to agree. It matches the error message given by PHP on signature mismatch (it adds the ?
even if not present in the signature).
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.
To be fair, array()
vs []
is just syntactic sugar, where as string $foo = null
would actually be a type mismatch. But I understand the reasoning as of why you want to keep it out for now. I think with new features that do not require merging from 3.x, it should be fine though (so this change can stay without ?
).
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.
would actually be a type mismatch
It's not: setting null as default value means the type is nullable. You're over-interpreting here, this is also syntactic sugar.
Thank you @louhde. |
…ovider to get the default filter (louhde) This PR was merged into the 4.2-dev branch. Discussion ---------- [Security] Allow passing null as $filter in LdapUserProvider to get the default filter | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - Commits ------- c6f87c6 [Security] Allow passing null as $filter in LdapUserProvider to get the default filter