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 <users@myfaces.apache.org>
>
>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/users@myfaces.apache.org/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

Reply via email to