It appears HtmlResponseStateManager uses jsf_tree *OR* jsf_tree_64 . Can anyone give me a high level idea about the different circumstances that would affect this? For example, when does SerializedView.getStructure() return a String?
Likewise, for jsf_state and jsf_state_64. ---- Original message ---- >Date: Wed, 12 Oct 2005 15:57:59 -0400 >From: Mike Kienenberger <[EMAIL PROTECTED]> >Subject: Re: t:saveState server/client ... or request/session >To: MyFaces Discussion <[email protected]>, [EMAIL PROTECTED] > >Werner, > >We're talking about encryption of the client state data at the client, >not of the data channel between the client and the server. Right now, >an end-user can do a view-source, then Base64 decode the state tree >field to see all stored data. Depending on what the application is >doing, this could contain sensitive information. It's a >recommendation of the JSF 1.2 spec to encrypt this data. > >On 10/12/05, Werner Punz <[EMAIL PROTECTED]> wrote: >> I do not think encryption is that important, signing probably yes, >> but if you want encryption you always can switch to a ssl layer which >> is easier to handle. >> >> >> >> >> Mike Kienenberger wrote: >> > I did a search on the JSF 1.2 spec, and the four references to >> > encrypting are all vague and general ("It is advisable that this >> > [client saved state] information be encrypted and tamper evident, >> > since it is being sent down to the client, where it may persist for >> > some time."), so we're on our own here. >> > >> > There's a few different approaches. The first is to simply generate >> > a new key on startup and effectively expire all sessions when the >> > server is restarted. It's not a bad "first draft" implementation. >> > However, it won't work in clustered environments nor across restarts. >> > >> > Saving the key in each session might work. The environment may >> > preserve server-side sessions across restarts, depending on the >> > configuration. >> > >> > Another approach is to find some centralized location to store the >> > encryption key. I'm not really sure what's available. Maybe a file >> > in "temp", and that has its own security concerns, but those are >> > probably subordinate to client-side state saving concerns. >> > >> > As you stated, you could also store the key in the application as an >> > unchangable attribute. Maybe that's not a bad way to go either, but >> > if that were the case, I'd like to be able to store it as a JNDI >> > property. I'd be a bit concerned about keeping the same key forever. >> > I think some "random" data would need to be padded into the state >> > values, especially for shorter state values, in order to keep the >> > encryption secure. >> > >> > I'd also like to recommend that the data is signed rather than just >> > encrypted. For me, having a cryptologically-signed state is more >> > important than encrypting the state. I'm not concerned that the >> > end-user can read the state (after all, most of the state is visible >> > in another form already). I just don't want the end- user to be able >> > to modify it. >> > >> > On 10/11/05, Dennis Byrne <[EMAIL PROTECTED]> wrote: >> > >> >> Dennis Byrne
