出自:http://www.mail-archive.com/users@myfaces.apache.org/msg45187.html
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.
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.
本文探讨了在使用MyFaces框架时,设置STATE_SAVING_METHOD为客户端可能导致的问题,特别是应用重新部署后出现的BadPaddingException异常。文章分析了问题根源在于StateUtils类中的一个bug,并提供了两种解决方案:显式禁用加密或设置密钥。

被折叠的 条评论
为什么被折叠?



