On 03.11.2010, at 14:44, Bernhard Schussek wrote:

> The last solution is to have two properties in your class of which one
> contains the plain text password (which is not persisted) and the
> other the persisted hashed password.
> 
> class User
> {
>  /**
>   * @validation:MinLetters(1)
>   */
>  protected $password;
> 
>  /**
>   * @PersistMe
>   */
>  protected $hashedPassword;
> 
>  public function setPassword($password)
>  {
>    $this->password = $password;
>    $this->hashedPassword = hash_me($password);
>  }
> }
> 
> IMO that last solution is the cleanest one, because it works
> regardless of whether you call setPassword() from a form or from
> somewhere else.


right ..  i agree. and this was actually the first thing i wanted to do when i 
realized how the validation currently works. but i dont like doing this work 
inside the entity, since its already done inside the EM. of course you can say 
its better to keep the entity independent of the EM.

anyway, i found that lifecyclecallbacks do not get this information passed to 
them .. only if you register a listener do you get the fetched version of the 
data to do this kind of comparison and this is of course way to heavy in terms 
of code written and code executed.

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]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en

Reply via email to