Thanks Les for the quick response and pointing me to the right direction. Yes it's the problem described and fixed in https://issues.apache.org/jira/browse/KI-46 and there is a unit test for it in WebRememberMeManagerTest, as part of 1.0-SNAPSHOT. For now, I copied the ensurePadding() method to my patched up anonymous WebRememberMeManager implementation. Will wait for the ki-> shiro rename before I start using 1.0-SNAPSHOT.
Kalle On Mon, Jun 15, 2009 at 10:26 AM, Les Hazlewood<[email protected]> wrote: > Hi Kalle, > > There isn't an existing unit test that I'm aware of for this particular > problem. > > The default key is stored as a private static final attribute in > BlowfishCipher as the KEY_BYTES constant. Also look at the bottom of that > class's source code for a Main method (which should be moved over into a > unit test) for ideas for a test case. > > The only thing I can think of is that there was something mentioned a while > back about quick fix to add back an extra "=" at the end of the > Base64-encoded string before trying to decode it - either it was not there > in the cookie, or it was being stripped off, or something to that effect. > > I don't know if this is even related to the problem you're seeing, but it > very well could be. I'd be very grateful for tests that could replicate and > show us how to fix it! > > Thanks, > > Les > > On Mon, Jun 15, 2009 at 12:49 PM, Kalle Korhonen > <[email protected]> wrote: >> >> There was an earlier thread with a similar issue I'm having (on Jan >> 26th, see http://markmail.org/message/hnbla673zygjgdcc). Trying to use >> WebRememberMeManager fails with IllegalBlockSizeException in >> AbstractRememberMeManager for me, the relevant stack trace lines are: >> >> [WARN] subject.AbstractRememberMeManager There was a failure while >> trying to retrieve remembered principals. This could be due to a >> configuration problem or corrupted principals. This could also be due >> to a recently changed encryption key. The remembered identity will be >> forgotten and not used for this request. >> java.lang.IllegalStateException: Unable to crypt bytes with cipher >> [javax.crypto.cip...@fee56]. >> at >> org.jsecurity.crypto.BlowfishCipher.crypt(BlowfishCipher.java:190) >> at >> org.jsecurity.crypto.BlowfishCipher.crypt(BlowfishCipher.java:214) >> at >> org.jsecurity.crypto.BlowfishCipher.decrypt(BlowfishCipher.java:139) >> at >> org.jsecurity.subject.AbstractRememberMeManager.decrypt(AbstractRememberMeManager.java:246) >> ... and later... >> Caused by: javax.crypto.IllegalBlockSizeException: Input length must >> be multiple of 8 when decrypting with padded cipher >> >> I'm using jsecurity 0.9 and programmatically initializing my managers >> (initing rememberme simply with new WebRememberMeManager() and setting >> it to my security manager). The suggested resolutions in the earlier >> thread don't make sense to me. I couldn't find where the default >> cipher key is in JSecurity and I also tried by setting a key manually >> but it didn't work any better. To me, this sounds suspiciously like a >> problem somewhere in the byte array to string conversion (similar to >> what's described at >> http://forums.sun.com/thread.jspa?threadID=5363535&tstart=0). I was >> using a String principal then changed it to a byte array but got >> unchanged results. I'm using Tomcat as the container. >> >> It looks like it should be fairly easy to write a unit test to assert >> the behavior to isolate the issue but before I proceed to do so, would >> anybody have any good guesses of what might go wrong or know if >> there's already a unit test for this? I didn't see any tests that >> would already cover this fully (only one for partially testing the >> cookie attribute). >> >> Kalle > >
