Hey Dennis, Rather than try to implement this per component (like with saveState/safeState), why not just implement it once in the stateManager? saveState and every other component all go through this anyway.
It's probably just a matter of checking the JSF 1.2 spec and insuring that what you're doing meets what's there (although, to be honest, since MyFaces is only 1.1 compliant, it doesn't have to meet the JSF 1.2 spec -- someone else can deal with that. Dealing with it now would just make the upgrade path easier in the future.) -Mike On 10/6/05, Dennis Byrne <[EMAIL PROTECTED]> wrote: > I can't commit myself to this for every component in the > project Martin. I have however created a sibling of > saveState called safeState . It acts just as saveState > except it makes use of an EncryptionUtil . > > EncryptionUtil uses several classes under javax.crypto, so > there are no third party deps. Unfortunately the static key > generator presents a challenge in a cluster. I haven't had > problems after a search and replace on all t:saveState tags > for my project. Can't say how it would perform in a high > volume environment. I also have unit tests. If this ends up > behaving itself in my project over a week or two, are you > interested? > > > ---- Original message ---- > >Date: Wed, 5 Oct 2005 09:30:21 +0200 > >From: Martin Marinschek <[EMAIL PROTECTED]> > >Subject: Re: t:saveState server/client ... or > request/session > >To: MyFaces Discussion <[email protected]> > > > >Ok, > > > >to shed some light on this: > > > >- in the JSF RI, there is encryption on the client side - we > have not > >implemented it so far, (this was after 1.1) cause we have no > one here > >with too much time and experience in this. It should be not > too hard > >though with the RI as an example and the java security > classes! Anyone > >fancy working on this? > > > >- on the server end of things, the RI saves the state of the > last 15 > >requests or so - this has been after 1.1. as well, and > nobody had the > >time to do so on our side either... any contributions here > are very > >welcome! > > > >- MyFaces is serializing whatever the state saving settings > are. So > >with MyFaces, you get a smaller memory footprint on the > server when > >the session is serialized, but the implementation does the > additional > >work of serialization/deserialization. I really think we > should have > >this as an option, any contribution is very welcome here as > well! > > > >regards, > > > >Martin > > > >On 10/5/05, Dennis Byrne <[EMAIL PROTECTED]> wrote: > >> >I guess it would be possible to implement a custom > >> >state-saving/state-restoring mechanism that encrypts the > >> data using a > >> >key stored in the user session. > >> > >> ... or use a converter that did the encryption/decryption ? > >> > >> >Why would the objects stored in the user session on the > >> server be > >> >serialized at all, unless webserver clustering is enabled? > >> > >> This is a good point and it probably explains the question > I > >> asked in a post that hit the list about 15 minutes ago. I > >> was under the impression the value was serialized in both > >> scenarios from past discussions I have had on the list. > >> > >> http://www.mail- > >> archive.com/[email protected]/msg08176.html > >> > >> >That does lead to some pretty heavy memory management at > the > >> server end. > >> > >> What if it was serialized to disk Simon ;-) > >> Dennis Byrne > >> > > > > > >-- > > > >http://www.irian.at > >Your JSF powerhouse - > >JSF Trainings in English and German > Dennis Byrne >
