Yes, I work in banking, so I tend to see the world through "paranoid color glasses", my above replies really only scratch the surface of required precaution, but you get the idea. For most people, "state in the client" + cookies or RPC tokens will do. Also, the GWT compiler/ optimizer/minimizer makes it damn hard to even have a chance of understanding the generated JS, let alone hack it.
That said, if your site is public facing, you should take some reasonable measures to protect it. On Jul 6, 9:26 pm, "brett.wooldridge" <[email protected]> wrote: > Nice. And as noted by Dean, this is a financial/banking application. > You have to go the extra mile and then some in that case. That said, > most of the "rest of us" (including the likes of gmail, ebay, > facebook) aren't overly concerned with user's messing with their > cookies. > > -Brett > > On Jul 7, 8:36 am, "Dean S. Jones" <[email protected]> wrote: > > > > > 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 -~----------~----~----~----~------~----~------~--~---
