Thank you for your answers. As you can see, I have already done the release.
Let's hope this is useful for someone :-)
Regards,
Daniel.
Eelco Hillenius wrote:
But the question here is... what is the real use of the ICryptFactory today
(1.3.0-rc1) in wicket? Is it "only" encrypting URLs? (I see
PasswordTextFields are not encrypted anymore)
Yep, I think we removed the other uses. I don't know exactly from the
top of my head, but it is in the (recent) mail archives.
And if so, would it be of real use/need? Of course, It would increase much
(as much as Java can) the security of the URLs' encryption but, would you
see any other uses?
I can't really think of anything else besides that it is available as
a nice utility class.
If this is only used for encrypting URLs, and if I am not wrong, our
"WebApplication" class would also need something like this:
------(CODE WHICH WOULD GO INTO OUR "WebApplication" CLASS)------
@Override
protected IRequestCycleProcessor newRequestCycleProcessor() {
return new WebRequestCycleProcessor() {
@Override
protected IRequestCodingStrategy newRequestCodingStrategy() {
return new CryptedUrlWebRequestCodingStrategy(new
WebRequestCodingStrategy());
}
};
}
Something like that yeah :-)
And more important: can I consider wicket's ICrypt and ICryptFactory
interfaces *stable*? (at least until a stable 1.3.0 release). Have you got
any short-term plans for changing anything in this encryption
infrastructure?
That's definitively a stable interface. I don't see us changing that
any time soon. Btw, now that we are in RC mode, we won't be changing
any of the API unless there are very pressing matters, in which case
we'll have a vote about it. The idea is to enable users to just drop
in new versions/ jars in RC/ finals without having to fix for API
changes.
So, JasyptCrypt will always throw an exception if this method is called.
Currently in wicket, "setKey" is only called from
org.apache.wicket.util.crypt.ClassCryptFactory, which jasypt does not
extend, so this would not pose any problems for the future, but... could it
make sense that that "setKey" method were called by the developer anywhere
else? this would render jasypt integration quite complicated...
I guess we'll hear if that is a problem for someone :-)
Eelco
---------------------------------------------------------------------
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]
