Martin, I fully agree that the PasswordField enforces best practices in regards to password security. At the same time, it seems very inappropriate for a framework to dictate exactly how one should write the business side of the application or its logical structure (e.g. separating the from in two parts - one to create one to update) . I would think that there would be a class of applications where the reduced security of having the password field populated would be very much acceptable.
Once again, the issue w/ the password field has come up at least a few times with newcomers, and the suggestions are always less than satisfying (either change your app structure or extend the framework) from a new user's perspective. It seems to me that iit would be much better f the password field allowed for the option to display its content, but include in the documentation that doing so would be not be advisable and possibly indicates a security issue down the road. Regarding writing custom components to solve the problem : as easy it might be to write a custom component, it seems to me that there is a big conceptual barrier that a new user has to overcome when switching between "just using" the framework and "extending" it (e.g. writing custom components). With T5 coming closer to a GA release, there will be more and more newcomers, who should be welcomed and not thrown into the deep side of the pool. Cheers, Alex Kotchnev On Tue, Sep 2, 2008 at 3:57 PM, Martijn Brinkers <[EMAIL PROTECTED]>wrote: > 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] > >
