My recent experience was to not trust the client AT ALL. If you send any info to the client ( Cookie, or a token to be sent back on RPC ), someone with knowledge enough could use a JS debugger and modify the memory containing the token, and your busted.
Personally, I use multiple methods. Everything is over https, the cookies are marked secure. The cookie is reset each request with a value from initial sign in, plus a "next sequence number" that is... non linear, and SHA-1 encoded. The SHA'd cookie value, a "state token***" + IP address of the last request are recorded in "shared memory" in the cluster(Terracotta) for the session ID. If the next request does not match, or the source IP does not match, we refuse the RPC, kill the session, and redirect them back to sign in. ( We don't worry about the various cases when a source IP can change ( this is banking software ), because the clients ID is associated with a whitelist IP range for the clients registered sites/proxies/gateways), each RPC IP then is also checked against the client whitelist. The "state token***" is sort of a FSM key - for any given action/screen, the "possible next request" is a known subset of all operations in the system. The request must be in that set - or a "navigation" to another higher level in the theoretical FSM. i.e. if you last request was "fetch portfolio instruments", the next can only be portfolio operations, or nav "higher", not an arbitrary "change user settings" RPC, etc. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
