You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by lesterburlap <nb...@voyence.com> on 2011/11/21 06:41:02 UTC
wicket url encoding: ClassCastException using SunJceCrypt
Hello:
I've followed the straightforward instructions for implementing URL encoding
that are available here:
https://cwiki.apache.org/WICKET/url-coding-strategies.html
When my page renders, I get the following ClassCastException. I haven't
been able to find others having this particular problem. I noticed in the
instructions that Wicket "uses the CryptFactory registered with the
application to encode and decode the URL." Could I perhaps have something
crypto-related misconfigured elsewhere?
Caused by: java.lang.ClassCastException:
com.sun.crypto.provider.PBEKeyFactory$PBEWithMD5AndDES cannot be cast to
javax.crypto.SecretKeyFactorySpi
at javax.crypto.SecretKeyFactory.getInstance(Unknown Source)
at
org.apache.wicket.util.crypt.SunJceCrypt.generateSecretKey(SunJceCrypt.java:119)
at org.apache.wicket.util.crypt.SunJceCrypt.crypt(SunJceCrypt.java:96)
at
org.apache.wicket.util.crypt.AbstractCrypt.encryptStringToByteArray(AbstractCrypt.java:163)
at
org.apache.wicket.util.crypt.AbstractCrypt.encryptUrlSafe(AbstractCrypt.java:86)
at
org.apache.wicket.protocol.http.request.CryptedUrlWebRequestCodingStrategy.encodeURL(CryptedUrlWebRequestCodingStrategy.java:201)
at
org.apache.wicket.protocol.http.request.CryptedUrlWebRequestCodingStrategy.encode(CryptedUrlWebRequestCodingStrategy.java:121)
at org.apache.wicket.RequestCycle.encodeUrlFor(RequestCycle.java:793)
Thanks for any suggestions or hints!
L. Burlap
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/wicket-url-encoding-ClassCastException-using-SunJceCrypt-tp4090613p4090613.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket url encoding: ClassCastException using SunJceCrypt
Posted by lesterburlap <nb...@voyence.com>.
Igor Vaynberg-2 wrote
>
> jsessionid is managed by the servlet container. we cant encrypt it
> because its not part of the page path or query string, its in its own
> weird ;jsessionid thing that containers mangle in there. maybe your
> container has an option to encrypt it, or maybe you can write a plugin
> for it that encrypts it...
>
Yeah, there is no Wicket problem here. I caught the WebResponse in the
debugger at the end of a request cycle, and there was no jsessionid in
there. The container is somehow magically pre-pending it to every single
url in the response markup.
For most situations, I think the newish WebSession.replaceSession (post 1.4)
takes care of the "session fixation" problem. There's also a Tomcat valve
(post 5.5.29) that issues a new session id after authentication: <Valve
className="org.apache.catalina.authenticator.FormAuthenticator"
changeSessionIdOnAuthentication="true" />
But messing with the session id for me invokes chaos with the underlaying
legacy auth layer I'm dealing with.
Wicket is still awesome, though!
L. Burlap
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/wicket-url-encoding-ClassCastException-using-SunJceCrypt-tp4090613p4094435.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket url encoding: ClassCastException using SunJceCrypt
Posted by Igor Vaynberg <ig...@gmail.com>.
jsessionid is managed by the servlet container. we cant encrypt it
because its not part of the page path or query string, its in its own
weird ;jsessionid thing that containers mangle in there. maybe your
container has an option to encrypt it, or maybe you can write a plugin
for it that encrypts it...
-igor
On Mon, Nov 21, 2011 at 9:32 AM, lesterburlap <nb...@voyence.com> wrote:
>
> lesterburlap wrote
>>
>> Caused by: java.lang.ClassCastException:
>> com.sun.crypto.provider.PBEKeyFactory$PBEWithMD5AndDES cannot be cast to
>> javax.crypto.SecretKeyFactorySpi
>> at javax.crypto.SecretKeyFactory.getInstance(Unknown Source)
>> at
>> org.apache.wicket.util.crypt.SunJceCrypt.generateSecretKey(SunJceCrypt.java:119)
>>
>
> I'm guessing now that this issue must be a classpath version conflict of
> some sort between PBEKeyFactory and SecretKeyFactorySpi. So, just for
> giggles, I went down the route of implementing the Wicket "TrivialCrypt",
> just to see if I could get URL encrypting to work at all. That worked fine.
>
> However, the jsessionid still shows up in the URL, which was the entire
> reason I was wanting to encrypt the URL:
> http://localhost:8080/app/;jsessionid=1xb3ytqs2y4ch?x=ydXFzcXFxcU
>
> So, dang it.
>
> My whole point here is to prevent the "session fixation" security
> vulnerability with the JSESSIONID cookie being set on a (supposedly
> stateless) Login Page. Calling WebSession.replaceSession() after Login to
> generate a new session id does not work for me because of some legacy
> authentication junk my Wicket app sits on top of (it relies on the session
> id to remain the same, or it totally freaks out).
>
> So, I've suppressed the JSESSIONID cookie from being written when the
> stateless Login Page loads (by setting an expired JSESSIONID cookie before
> the response is sent). And also overriding WebApplication.newWebResponse so
> that it doesn't encode the jsessionid. But then that causes wicket to stick
> the session id in new URLs after login (I guess because the JSESSIONID
> cookie is not present in the login POST data).
>
> Good times. I think I have officially been defeated.
>
> LBB
>
> --
> View this message in context: http://apache-wicket.1842946.n4.nabble.com/wicket-url-encoding-ClassCastException-using-SunJceCrypt-tp4090613p4092331.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket url encoding: ClassCastException using SunJceCrypt
Posted by lesterburlap <nb...@voyence.com>.
lesterburlap wrote
>
> Caused by: java.lang.ClassCastException:
> com.sun.crypto.provider.PBEKeyFactory$PBEWithMD5AndDES cannot be cast to
> javax.crypto.SecretKeyFactorySpi
> at javax.crypto.SecretKeyFactory.getInstance(Unknown Source)
> at
> org.apache.wicket.util.crypt.SunJceCrypt.generateSecretKey(SunJceCrypt.java:119)
>
I'm guessing now that this issue must be a classpath version conflict of
some sort between PBEKeyFactory and SecretKeyFactorySpi. So, just for
giggles, I went down the route of implementing the Wicket "TrivialCrypt",
just to see if I could get URL encrypting to work at all. That worked fine.
However, the jsessionid still shows up in the URL, which was the entire
reason I was wanting to encrypt the URL:
http://localhost:8080/app/;jsessionid=1xb3ytqs2y4ch?x=ydXFzcXFxcU
So, dang it.
My whole point here is to prevent the "session fixation" security
vulnerability with the JSESSIONID cookie being set on a (supposedly
stateless) Login Page. Calling WebSession.replaceSession() after Login to
generate a new session id does not work for me because of some legacy
authentication junk my Wicket app sits on top of (it relies on the session
id to remain the same, or it totally freaks out).
So, I've suppressed the JSESSIONID cookie from being written when the
stateless Login Page loads (by setting an expired JSESSIONID cookie before
the response is sent). And also overriding WebApplication.newWebResponse so
that it doesn't encode the jsessionid. But then that causes wicket to stick
the session id in new URLs after login (I guess because the JSESSIONID
cookie is not present in the login POST data).
Good times. I think I have officially been defeated.
LBB
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/wicket-url-encoding-ClassCastException-using-SunJceCrypt-tp4090613p4092331.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org