That still wouldn't solve the validation issue. If the user doesn't input
anything, validation will fail.
Uli
Am Di, 2.09.2008, 22:39, schrieb Carl Crowder:
> Why not just @Persist the password value in the session, only
> overwriting the value if the user submits something? That way the value
>
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 fo
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.
Why not just @Persist the password value in the session, only
overwriting the value if the user submits something? That way the value
gets kept but at the same time the clientside doesn't have the plaintext
password.
Thiago H. de Paula Figueiredo wrote:
> Em Tue, 02 Sep 2008 16:57:19 -0300, Martij
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 t
Em Tue, 02 Sep 2008 16:57:19 -0300, Martijn Brinkers
<[EMAIL PROTECTED]> escreveu:
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
i
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
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
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
Ah, I see. Yeah, something like that in the PasswordField would be sweet.
-Filip
On 2008-09-02 16:58, Ulrich Stärk wrote:
Filip,
validation would still fail then because passwordfield blanks the output
value, i.e. the textfield is empty upon form submission. That's okay for
creating new instan
Filip,
validation would still fail then because passwordfield blanks the output
value, i.e. the textfield is empty upon form submission. That's okay for
creating new instances but not when editing existing ones where the field
already contains data. The only solution I see is to do the validation
Hi Ulrich,
Just guessing here, but how about setting t:validate="minlength=1" on
the field? This will pass if the field is empty, afaik. Of course, you
can set it to the real minimum length of the password and add a
maxlength as well.
That should do the trick.
-Filip
On 2008-09-02 16:17, U
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 c
13 matches
Mail list logo
