Re 3) I think the behavior makes sense in most circumstances, though it breaks down in a few ways:
1) I would personally like to not accept invalid values into the setter at all - coding in validation so that the Entity itself will not accept bad data, and this isnt possible at the current time with the form/validation framework (open to ideas or rebuttals, I dont know if this is a good idea or not?) 2) I would like to start by saying I am against specifying arbitrary rules for passwords, I do not believe it is the developer who should be in charge of password strength. Providing an interface to educate the user about password strength is more appropriate than telling them "YOU MUST HAVE A NUMBER!". Aside from that, it does present an issue: how can you validate a value that is mangled and not stored in plain text in the Entity? A password is one case, but what about creditcard numbers? They should be encrypted on entry and only be allowed to be decrypted when you NEED the numbers. (If stored at all - in a PCI compliant way, of course) Wish I had a solution. I would really like to prevalidate values before binding them to the Entity (or while, I dont know the architecture of the Form/Validator well enough). t On Wed, Nov 3, 2010 at 18:52, Lukas Kahwe Smith <[email protected]>wrote: > Hi, > > So I was working on figuring out what the problem is with the form > validation not working when using DoctrineUserBundle (point #5 on > http://pooteeweet.org/blog/1853). Since then I have found out a few > things: > > 1) Annotation validation seems broken. I only got validation to work using > XML (didnt try YAML) > > I have created ticket: http://trac.symfony-project.org/ticket/9218 > > 2) RepeatedField() does not seem to "copy" the validation rules into the > build group > > Aka $this->add(new RepeatedField(new PasswordField('password'))); this only > applies validation that the two generated password fields match. But the > validation rules defined on password are not applied > > I have created ticket: http://trac.symfony-project.org/ticket/9219 > > 3) Validation rules seem to be applied on the values after the setter aka > not on the raw original data > > Now I was quite surprised to find that some people think this even makes > sense. To me its clear that you validate data before you process it. Thats a > fundamental rule of security. I do acknowledge that there might be use cases > where you want to validate the data once again before you submit it to a > database, but that to me is an edge case. > > The issue I was facing was that it seemed like "password" validation rules > were not applied. Turns out the issue was that there was encryption being > applied in the setter, because it turned whatever was submitted into a non > blank, more than 8 character containing at least one number or special char > (my validation rules): > public function setPassword($password) > { > if (empty($password)) { > $this->password = null; > } > > $this->password = $this->encryptPassword($password); > } > > Overriding the setter to not do any encryption made the validation rules > work (note doing that change didnt fix the RepeatedField issue in case you > are wondering). > > I have not created a ticket, because people on twitter seemed to think that > the current behavior actually makes sense and that for example in the above > case, they store the clear text password in the object and use life cycle > events to encrypt the password when they store the user in the database. > > To me this seems wrong. Again you validate user input as soon as possible > and certainly not after applying some logic to it. This is also important > for being able to return the user the original text they entered in case of > a validation failure. Furthermore what if I have some issues with my > lifecycle events, like someone screws up the configuration when using > inheritance, suddenly I am storing passwords in clear text. Seems like the > opposite of defensive programming. Furthermore later on when I retrieve the > user from the database I will not have the clear text password either, so it > seems like it means I need to do all sorts of logic to handle if the > password is encrypted or not. Anyway, I am focusing a lot on one use case > here. I am open to hear why people think the current behavior makes sense. > > regards, > Lukas Kahwe Smith > [email protected] > > > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<symfony-devs%[email protected]> > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
