Normally you get a session ID from the server and store that in a cookie and use the session id to make sure the user is actually logged in.
-- Arthur Kalmenson On Tue, Aug 4, 2009 at 9:16 AM, jahboite<jahbo...@gmail.com> wrote: > > Hello GWTers! > > Having read the XSRF and GWT section of the page at > http://groups.google.com/group/Google-Web-Toolkit/web/security-for-gwt-applications > I'm trying to implement the suggested protection which involves > sending an extra 'cookie value' param in GWT calls and then comparing > that value with the value of the cookie header. > > My question involves the generation of the cookie value and whether it > is safe to do this on the client. As long as it doesn't impact client > performance, it seems to me that generating a random token, setting > the cookie with that token and sending the same token as a param in > RPC calls would be a neat way to offload CPU cycles to the client. > The server would then only need to compare the cookie header with the > token received in each RPC call and drop the call if the values don't > match (on the assumption that the call hasn't been made by the logged- > in client). > > Is that safe? Is there a way for a forged request to include a > cookie? If the server merely compares two arbitrary strings, wouldn't > it be easy for a forger to bypass the restrictions relied upon for > this type of protection? > > Any insights gratefully received. > > Cheers. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
