[Security] Allow passing null as $filter in LdapUserProvider to get the default filter #27850
Conversation
| 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.
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.
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.
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.
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.
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.
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