I agree that in theory it's always better to have a choice than not. Although in practice I think that most beginning developers would just skip the security warnings when the result is what they 'expected'. If the result is unexpected (like in the password field gets cleared) they start looking for reasons why. That said, I agree with you that you should make it easy and fun for first time Tapestry users so in that respect I can see your point.
Martijn About the name, not problem. I guess you hardly see names with "ij" outside of the Netherlands (can only think of Dijon, the mustard ;) so I can imagine readers think it's a typo :) On Tue, 2008-09-02 at 16:40 -0400, Alex Kotchnev wrote: > 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] > >> > >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
