I can answer the 2nd the fastest. It does make sense to have Tomcat or whatever server handle things, until you have a multi-server cluster. Then typical session management ideals are tossed out the window.
On Dec 29, 7:10 am, akutz <sak...@gmail.com> 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? > > 2) What is wrong with simply relying on the normal Tomcat (et al) > method of handling sessions? Perhaps I simply wish to store some > information once the client has logged in via an authentication back- > end that I do not control. Why do I need to send the SID along with > each request? The client and server already automagically connect each > incoming client request with the correct session bag (or I thought > this happened). > > Thank you for your time! --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
