Personally I think the way it works now is how it should be. Imho passwords should never be retrievable because they should have been hashed and therefore no longer available as a plain text password. I really distrust applications that do not hash passwords. The mentioned problem can be solved my making a distinction between adding a new user (which requires a password) and editing a user (allow blank password indicating that the password should not be changed).
Martijn Brinkers On Tue, 2008-09-02 at 15:44 -0400, Alex Kotchnev wrote: > Seriously, we have to do away with such one-off hacks and provide support > for such common use cases in the framework. I was thinking today that as > much as the "blanking" of the password fields represents best practice for > handling passwords, it still seems that a whole bunch of uses of the > password field become unpleasantly complicated because of it. Is there a > possibility of making the default PasswordField behavior to blank out the > value, but provide a flag to the component that would output it ? > > Overall, my point is that in situations like this "write your own component" > seems to be unacceptable advice. A newcomer to the framework shouldn't have > to write custom components to solve common problems, they should be solved > by the framework.. > > Just my 2c. > > Cheers, > > Alex K > > On Tue, Sep 2, 2008 at 1:23 PM, Thiago H. de Paula Figueiredo < > [EMAIL PROTECTED]> wrote: > > > Em Tue, 02 Sep 2008 11:27:32 -0300, Markus Joschko < > > [EMAIL PROTECTED]> escreveu: > > > > Hi Ulrich, > >> the current PasswordField component always blanks the value. > >> If you really want to keep the password (might result into security > >> and usability issues as the user has no chance to check whether the > >> value is valid and the password will be unencrypted in the HTML), > >> write your own password component that extends from AbstractTextField > >> but does not blank the value. > >> > > > > My approach is a little bit radical: I disable the password field when > > editing an user and provide another form jsut for password changes. > > > > Thiago > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
