Skip to content

[Security] decoupled UserPassword constraint from SecurityBundle #6892

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

Closed

Conversation

hhamon
Copy link
Contributor

@hhamon hhamon commented Jan 27, 2013

Q A
Bug fix? no
New feature? no
BC breaks? yes (for people already using the UserPassword constraint class in their code)
Deprecations? no
Tests pass? yes
Fixed tickets #6889
License MIT
Doc PR -

Hugo Hamon added 2 commits January 27, 2013 17:18
…lidator classes to fit the coding convention. Also added a bunch of unit tests to validate the UserPasswordValidator object and introduced a new UserPassword constraint class in the SecurityBundle. The base UserPassword constraint class in the Security component is now decoupled from the SecurityBundle.
@stof
Copy link
Member

stof commented Jan 27, 2013

👎

Changing the class name is an unnecessary BC break, and your base class in the bridge is totalmy useless as it tells that its validator is a new instance UserPasswordValidator which won't work.

@hhamon
Copy link
Contributor Author

hhamon commented Jan 27, 2013

I don't have a new class in the bridge namespace. I just added a new UserPassword class in the SecurityBundle. Having the getValidatedBy method in the UserPassword class of the Security component adds a dependency between the component and the security bundle. That's why I introduced the UserPassword class in the SecurityBundle.

I can revert the BC break for the namespace if necessary.

@stof
Copy link
Member

stof commented Jan 27, 2013

@hhamon the getValidatedBy method of the class in the bridge (inherited from the base class now) makes this constraint totally unusable as it cannot be validated.

@hhamon
Copy link
Contributor Author

hhamon commented Jan 27, 2013

I don't really understand why it cannot be validated. How this constraint could be validated anyway by leaving it only in the security component? If I want to use the Security component without the DI component, I won't be able to use the current UserPassword constraint anyway as it requires to be validated with an unexisting service.

I can't understand why the current UserPassword class must be validated with a service defined in the SecurityBundle. The main goal of a component by nature is to be autonomous and it's not right now with the current implementation? Am I wrong then?

@stof
Copy link
Member

stof commented Jan 28, 2013

it cannot be validated by building a new instance of the validator when asked to validate the constraint, because the validator needs to have access to the SecurityContext.

@hhamon
Copy link
Contributor Author

hhamon commented Jan 28, 2013

I understand but that means the Security component must work with the DI component and the SecurityBundle so. This constraint can't be used as is anyway. So why don't we put it (with the validator) in the SecurityBundle in this case?

@@ -34,7 +34,7 @@ public function validate($password, Constraint $constraint)
$user = $this->securityContext->getToken()->getUser();

if (!$user instanceof UserInterface) {
throw new ConstraintDefinitionException('The User must extend UserInterface');
throw new ConstraintDefinitionException('The User must be an instance of the UserInterface interface.');
Copy link
Contributor

Choose a reason for hiding this comment

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

"implement" ? (instances of interface do not exist)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agreed.

@vicb
Copy link
Contributor

vicb commented Jan 29, 2013

I agree with @stof comments.

One more thing: the Constraints ns is an anomaly in Sf2 where ns almost never end with a "s". Are you going the wrong way here ?

@hhamon
Copy link
Contributor Author

hhamon commented Jan 30, 2013

Hi Victor,

Ok so I will drop this PR but I will open another one, which contains the unit tests for the validator.

Cheers.

@vicb
Copy link
Contributor

vicb commented Jan 30, 2013

Hi Hugo,

It might also be interesting to get @fabpot and @bschussek opinions about dropping the "s" - it should not happen before 3.0 I think (if it should at all).

@hhamon
Copy link
Contributor Author

hhamon commented Feb 2, 2013

Closing this PR in favor of #6947.

@hhamon hhamon closed this Feb 2, 2013
@fabpot
Copy link
Member

fabpot commented Feb 4, 2013

I'm +1 to rename Constraint to Constraints and keep the old name for 2.2 as an alias.

@hhamon
Copy link
Contributor Author

hhamon commented Feb 4, 2013

Ok will do. I'm opening a new PR.

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.

4 participants