GWT can support REST easily. See:
http://code.google.com/webtoolkit/doc/1.6/DevGuideServerCommunication.html The section on Making HTTP Request should help. Personally, I opt for standard GWT RPC, but I'm a spoiled Java coder. -Brett On Jul 7, 5:18 pm, ytrewqsm <[email protected]> wrote: > Thx a lot...i got a lot of information...i try now to process all of > it. > Still after first reading ,REST like application is based on url's and > stuff > How can that be applied to a GWT app which is based on RPC. > This is like a one page application....so ? > > On 7 Iul, 05:00, "Dean S. Jones" <[email protected]> wrote: > > > > > 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.- Ascundeţi textul citat - > > > - Afişare text în citat - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
