One possible cause of the issue could be that your submitted page values are exceeding some limit, and you're not getting the entire form submitted. Some setups have a 4K limit -- I've hit this on an Apache web server with a proxy server going to an Oracle app server.
Another possibility is that your generated html has some other output in the middle of your encrypted state data. I've seen things like exceptions written out in the middle of the data at times. And lastly it's possible that sometimes the generated html isn't completely written out. I've had this happen in certain situations with Oracle app servers, where the page generated wasn't flushed completely to the client, leaving a partial encrypted form value. So the next time it happens, save a copy of the original html that you're submitting from, and try to capture a copy of the form data you are submitting. Make sure that the generated html is intact and all there. And check to see how much data you're posting back to the server. On Wed, Jan 14, 2009 at 11:23 AM, <[email protected]> wrote: > > Hi Simon, > >> 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. > Tried it, didn't help. >> >> (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. > Tried it, didn't help. >> >> (3) use server-side state saving (only client-side state is encrypted) > Tried it, didn't help. >> </quote> > > > Felix >
