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
