You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Jonathan Harley <jo...@parkplatz.net> on 2007/12/10 19:31:12 UTC

Re: STATE_SAVING_METHOD=client issues

Gary Jackson wrote:
> I have an issue when STATE_SAVING_METHOD is set to client.  If I 
> undeploy and redeploy the application while the application is being 
> used, I get a "javax.crypto.BadPaddingException: Given final block not 
> properly padded".  Presumably this is happening because MyFaces is 
> attempting to recover invalid state from a session that is no longer 
> valid.  Is this a common problem?  How do people normally get around this?

Yes, I've been having this problem too and have just got to the bottom
of it. It has been mentioned a few times on this list going back to early
2007 but I never saw a solution before.

The problem is a bug in the StateUtils class. Encryption of client-side
state saving is supposed to be off unless you enable it, but is in fact
ON unless you DISABLE it!

The problem is that if you don't specify a secret (because you think
you're not using encryption), MyFaces will generate one and place it
in application context; but this will change when you redeploy, and
the secret used in pages in users' browsers from before the redeploy
will then fail.

I've logged this as a bug in the ASF JIRA (it is issue
MYFACES-1786), but the workaround is either to explicitly
disable encryption, like this:

<context-param>
     <param-name>org.apache.myfaces.USE_ENCRYPTION</param-name>
     <param-value>false</param-value>
</context-param>

(note that "false" must be in lower case!) or to set a secret.


Jonathan.
-- 
.....................................................................
           Dr Jonathan Harley   .
                                .   Email: jon@parkplatz.net
            Zac Parkplatz Ltd   .   Office Telephone: 024 7633 1375
            www.parkplatz.net   .   Mobile: 079 4116 0423