Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[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

Merged
merged 1 commit into from
Jul 7, 2018
Merged

[Security] Allow passing null as $filter in LdapUserProvider to get the default filter #27850

merged 1 commit into from
Jul 7, 2018

Conversation

louhde
Copy link

@louhde 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})';
}
Copy link
Contributor

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?

@@ -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)
Copy link
Contributor

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.

Copy link
Member

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 [].

Copy link
Member

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).

Copy link
Contributor

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 ?).

Copy link
Member

@nicolas-grekas nicolas-grekas Jul 6, 2018

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.

@nicolas-grekas
Copy link
Member

Thank you @louhde.

@nicolas-grekas nicolas-grekas merged commit c6f87c6 into symfony:master Jul 7, 2018
nicolas-grekas added a commit that referenced this pull request Jul 7, 2018
…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
@nicolas-grekas nicolas-grekas modified the milestones: next, 4.2 Nov 1, 2018
This was referenced Nov 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants