> About this topic, I am the founder of a project called Jasypt (Java
> Simplified Encryption) [http://www.jasypt.org], which is aimed at easily
> adding robust encryption capabilities to java applications, be it password
> digesting or two-way text, binary, or number encryption (based on any JCE
>
Martijn Dashorst wrote:
> Ok, my bad: you need to provide your own type...
>
> So create a MyRequiredPasswordTextField, and override the
> getInputType() and have it return "password"
>
> Martijn
K. That makes much more sense. Thx.
BTW, I'm curious to hear if anyone has any thoughts about the
Ok, my bad: you need to provide your own type...
So create a MyRequiredPasswordTextField, and override the
getInputType() and have it return "password"
Martijn
On 7/19/07, David Rosenstrauch <[EMAIL PROTECTED]> wrote:
> Martijn Dashorst wrote:
> > PasswordTextField {
> > protected String g
Martijn Dashorst wrote:
> PasswordTextField {
> protected String getInputType()
> {
> return "password";
> }
> }
>
> TextField {
> /**
>* Subclass should override this method if this textfields mappes on
> a different
>* input type as text. Lik
PasswordTextField {
protected String getInputType()
{
return "password";
}
}
TextField {
/**
* Subclass should override this method if this textfields mappes on
a different
* input type as text. Like PasswordField or HiddenField.
Daniel Fernández Garrido wrote:
> David, I think your problem (not wanting password to come encrypted from the
> input component) would be solved by simply making your Application object
> return your own implementation of the
> wicket.settings.ISecuritySettingsinterface for its getSecuritySettings
Martijn Dashorst wrote:
> On 7/19/07, David Rosenstrauch <[EMAIL PROTECTED]> wrote:
>> Martijn Dashorst wrote:
>>> It is configurable: don't use PasswordTextField but TextField instead.
>> No. If you try to use a TextField, then wicket will insist that you
>> convert your HTML to use instead of >
David, I think your problem (not wanting password to come encrypted from the
input component) would be solved by simply making your Application object
return your own implementation of the
wicket.settings.ISecuritySettingsinterface for its getSecuritySettings
method. And in this extension
(MySecuri
On 7/19/07, David Rosenstrauch <[EMAIL PROTECTED]> wrote:
> Martijn Dashorst wrote:
> > It is configurable: don't use PasswordTextField but TextField instead.
> No. If you try to use a TextField, then wicket will insist that you
> convert your HTML to use instead of type="password"/> - and thus
Martijn Dashorst wrote:
> It is configurable: don't use PasswordTextField but TextField instead.
No. If you try to use a TextField, then wicket will insist that you
convert your HTML to use instead of - and thus lose the masked password entry capabilities
(i.e., echoing "*" characters).
>
On 7/19/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> Didnt it have to do with persistency of fields via cookies as well?
Yeah, didn't think of that too. Anything stored on the client is a
risk, so having the default to be secure is a real safeguard.
Martijn
--
Wicket joins the Apache Softwa
Hello,
About this topic, I am the founder of a project called Jasypt (Java
Simplified Encryption) [http://www.jasypt.org], which is aimed at easily
adding robust encryption capabilities to java applications, be it password
digesting or two-way text, binary, or number encryption (based on any JCE
p
On 7/19/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> It is configurable: don't use PasswordTextField but TextField instead.
>
> The reason behind PTF's encryption is that we want to provide a secure
> solution out-of-the-box. You can circumvent it, but then *you* need to
> open up Pandorra's b
It is configurable: don't use PasswordTextField but TextField instead.
The reason behind PTF's encryption is that we want to provide a secure
solution out-of-the-box. You can circumvent it, but then *you* need to
open up Pandorra's box, not us. Same with escaping markup while
outputting model valu
14 matches
Mail list logo
