> 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]
