I meant issue https://issues.apache.org/jira/browse/MYFACES-1838
Simon Kitching schrieb: > I've added a note on the bugzilla issue > https://issues.apache.org/jira/browse/MYFACES-1786: > > <quote> > I don't believe this is a bug at all. Unless I've misunderstood > something, it's just missing configuration. > > I think any of the following (in order of preference) should solve this: > > (1) in web.xml, define init-parameter "org.apache.myfaces.SECRET" to be > some reasonably long string. The server will then use the same > encryption secret after restart (instead of generating a key itself), > and so will be able to decrypt "old" sessions. > > (2) in web.xml, define init-parameter > "org.apache.myfaces.USE_ENCRYPTION" to be "false", in order to disable > client-side state encryption. Of course this potentially opens a > security hole in the app. > > (3) use server-side state saving (only client-side state is encrypted) > </quote> > > I also added a note on related issue MYFACES-1786: > <quote> > state *should* be encrypted by default; no system should default to > being insecure. > </quote> > > And by the way, this is all related to myfaces-core, and is nothing > whatsoever to do with Trinidad. I've therefore changed the email subject > line. > > Felix's original complaint is a little different from the jira issue > referenced. That issue triggers only on servlet-container restart while > Felix was claiming the problem popped up spontaneously. I suspect that > there was actually a container restart happening there (eg the container > is configured to "watch" for changes, and some watched file is being > touched). Felix, you might want to check your logs : I bet that whenever > this happens you are also getting a complete webapp restart, ie you've > got something weird in your environment. > > Regards, > Simon > > > > Cagatay Civici schrieb: >> I've seen this error even in myfaces 1.2.2. >> >> There's an annoying problem with client side viewstate encryption. >> >> On Wed, Jan 14, 2009 at 2:53 PM, Matthias Wessendorf <mat...@apache.org >> <mailto:mat...@apache.org>> wrote: >> >> Hi know that there is some param on myfaces core for this. >> So, does that work with MyFaces 1.2.6 standalone ? >> Did this used to before upgrading to Trinidad 1.2.10 ? >> >> -M >> >> On Wed, Jan 14, 2009 at 2:52 AM, <felix.bec...@t-systems.com >> <mailto:felix.bec...@t-systems.com>> wrote: >> > Hi, >> > >> > >> > >> > I've got a serious problem with my frontends. Extremely sudden the >> exception >> > below is thrown. Restarting the Container does not work. >> Redeploying doesn't >> > help immediately. I have to close all browser windows an redeploy the >> > application many times until it works. The error is not >> reproducible and >> > there is no root cause from one of our own classes. A simple >> frontend page >> > (small login) which works fine hundreds of time suddenly fails and >> the whole >> > application is down after this exception. >> > >> > >> > >> > Trinidad Version: 1.2.10 >> > >> > MyFaces 1.2.6 >> > >> > >> > >> > Is this problem / are any workarounds known? >> > >> > >> > >> > Shall I open a ticket in the JIRA? >> > >> > >> > >> > Regards >> > >> > >> > >> > Felix >> > >> > >> > >> > ==> logs/localhost.2009-01-14.log <== >> > >> > Jan 14, 2009 5:42:54 AM >> org.apache.catalina.core.StandardWrapperValve invoke >> > >> > SEVERE: Servlet.service() for servlet Faces Servlet threw exception >> > >> > javax.crypto.IllegalBlockSizeException: Input length must be >> multiple of 8 >> > when decrypting with padded cipher >> > >> > at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..) >> > >> > at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..) >> > >> > at >> com.sun.crypto.provider.DESCipher.engineDoFinal(DashoA13*..) >> > >> > at javax.crypto.Cipher.doFinal(DashoA13*..) >> > >> > at >> > >> >> org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:369) >> > >> > at >> > >> >> org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:411) >> > >> > at >> > >> >> org.apache.myfaces.shared_impl.util.StateUtils.decrypt(StateUtils.java:291) > >
