t:saveState server/client ... or request/session

[Dennis Byrne <de...@dbyrne.net>]

Regarding subtle differences when changing 
javax.faces.STATE_SAVING_METHOD to 'server' vs. 'client' . 
These differences appear to be forcing me to choose between 
two requirements : producing an application w/ 'context 
complete' requests and producing an app that is secure.

With 'client' side saving, every web form passes the "two 
browser window test" - form data does not get mixed up across 
different posts w/in the same HTTP session .  Each request is 
context complete, but at the expense of security (serialized 
objects are not encrypted, just encoded).

To no suprise, I get the opposite w/ 'server' side saving .  
I take it the serialized objects are tied to the session?  

If serialized objects are tied to the session, how hard would 
it be to pass a unique identifier w/ each rendering of 
t:saveState, so that JSF would be able to match each 
serialized storage w/ the correct response, which is not 
always the NEXT response?  How hard would it be to get client 
side saving to not just encode the data, but encrypt it as 
well?



Dennis Byrne

Re: t:saveState server/client ... or request/session

[Simon Kitching <sk...@obsidium.com>]

Dennis Byrne wrote:
> Regarding subtle differences when changing 
> javax.faces.STATE_SAVING_METHOD to 'server' vs. 'client' . 
> These differences appear to be forcing me to choose between 
> two requirements : producing an application w/ 'context 
> complete' requests and producing an app that is secure.
> 
> With 'client' side saving, every web form passes the "two 
> browser window test" - form data does not get mixed up across 
> different posts w/in the same HTTP session .  Each request is 
> context complete, but at the expense of security (serialized 
> objects are not encrypted, just encoded).

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.

> 
> To no suprise, I get the opposite w/ 'server' side saving .  
> I take it the serialized objects are tied to the session?  

Why would the objects stored in the user session on the server be 
serialized at all, unless webserver clustering is enabled? Without 
clustering, objects stored in the session are just held in memory and 
never serialised at all AFAIK.

> 
> If serialized objects are tied to the session, how hard would 
> it be to pass a unique identifier w/ each rendering of 
> t:saveState, so that JSF would be able to match each 
> serialized storage w/ the correct response, which is not 
> always the NEXT response?

That does lead to some pretty heavy memory management at the server end. 
The server needs to keep a large number of copies of the state. And 
assuming session timeout is set at 30 minutes, it would need to keep all 
that info around for 30 minutes after the user has walked away from 
their PC to have lunch/play golf/whatever.

So it's possible to implement, I guess, but I personally don't think any 
places would want to use that approach.

Storing multiple copies of the state on the client's PC is less 
problematic because the client machine doesn't have to handle many 
concurrent users. Of course it does increase the bandwidth required, as 
all the state is transferred to the client then back to the server for 
each request. But given the prolific use of images etc on sites 
these-days, that extra bandwidth is probably not significant.



   How hard would it be to get client
> side saving to not just encode the data, but encrypt it as 
> well?

That sounds like a good idea to me...


NB: The thing that ties two browser windows to the same session is the 
fact that they share their cookies. But cookies aren't the only way to 
implement Http sessions. There's URL encoding, where each URL has 
";jsessionid=....." on the end. And there's also "hidden field" 
approach, where each page has a hidden input field with name 
"jsessionid", though this requires all navigation to be done via POST 
commands which can be tricky. Maybe this can help you somehow?

I agree that encrypting the client-side state seems the nicest solution 
though.


Regards,

Simon