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
