Martijn, sorry for misspelling your name in the previous post, fat fingers on my end.
Cheers, Alex Kotchnev On Tue, Sep 2, 2008 at 4:38 PM, Alex Kotchnev <[EMAIL PROTECTED]> wrote: > 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] >> >> >
