If you do 1) you open yourself to XSRF attacks. Read this article (http://groups.google.com/group/Google-Web-Toolkit/web/security-for- gwt-applications) on how to avoid this by submitting a duplicate field with the cookie value and verifying it on the server end before executing the request For 2) the cookie is how tomcat figures out session to user relationship in the first place. I believe the cookie name is jsessionid for coorelating requests.
On Dec 29, 6:10 am, akutz <[email protected]> wrote: > Per the Login Security FAQ (http://code.google.com/p/google-web- > toolkit-incubator/wiki/LoginSecurityFAQ) I have a few questions: > > 1) We're storing the SID in a client-side cookie and then the GWT app > is grabbing that and sending it to the server with each RPC request. > How is that any different than getting the SID from the cookie on the > server side? Theoretically if an attacker can replace the cookie, then > wouldn't the GWT portion of the code that reads the cookie to send it > along with the RPC request pick up the replaced cookie anyway? > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
