you are right, we can not avoid that clear text is contained in the
markup which is send to the browser and we can not avoid that the
input received from the browser is clear text as well. Provided I
remember correct the idea was:
- help the user and provide them a dead simple functionality which can
handle sensitive data. The user simply needs to store the value
(encrypted string) in a database. The rest is done in a nice and easy
and secure way by Wicket
- rememberMe requires Cookies. Though there are probably other
solutions, one approach is to save the user id and password in a
cookie. At least the password cookie value should be encrypted.
Aren't these still valid use cases? Are there better solution to solve
these use cases? How have real world wicket applications implemented
these use cases?
-Juergen
On 8/15/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> i removed encryption support from passwordtextfield as it seems kinda funky
> to me.
>
> we would encrypt a value before rendering it, then decrypt it before
> applying it to the model.
>
> but how do you decrypt a user-entered string? so the field would start as
> <input value="encrypted"/>
> but then when submitted it would submit the clear text value, which we would
> then try to decrypt?
>
> also the current impl of
> protected final void onComponentTag(final ComponentTag tag)
> {
> super.onComponentTag(tag);
> tag.put("value", getResetPassword() ? "" :
> getModelObjectAsString());
> }
>
> would also always set the clear text value anyways :|
>
> -igor
>
