Thanks Alex & Jens, I have two separate applications where I'd like to use this approach to protect against XSRF attacks.
In one of them I'm seeing this problem with GWT in hosted mode so there is no login process at all. Eventually it will be put inside of an enterprise ear and will have a login process so given what you say that will solve the problem...but I still need a solution for hosted mode so I can develop/test. In the other app I'm planning to use method level security with Spring Security (AOP) so in this app there will not be a separate login app/ url process...it's just the GWT app. Personally I don't like the JSF/ JSP approach of redirecting to separate URLs/etc because I want one look for all of my GWT app not different for login/logout etc. And the redirect approach just doesn't seem to fit well in the RPC world. Thanks! -Dave On Jul 25, 4:58 am, Jens <[email protected]> wrote: > The session cookie should always be present because of your login process. > You don't need an XSRF token during login but once you have successfully > authenticated (and thus a session id is available) the very first thing to > do is to fetch a XSRF token from the server. So basically your login() and > getNewXsrfToken() methods are not protected with an XSRF token. > > Personally I like to have two apps, the first one is just a very small > login app (not necessarily a GWT app) that does not use XSRF Tokens at all > and the second app is the real GWT app. Once the real app starts the very > first thing it does is to fetch an XSRF token and then use it for all other > requests, like fetching the logged in user information which would probably > the second thing to do. If I can't get an XSRF token for any reason I > redirect to the login app. > In this scenario you could also use a dynamic host page for the real app > and let the server dynamically include the XSRF token and user information > right into the host page so you can read it with GWT using the Dictionary > class. That would save some requests on app startup. But personally I don't > do that for now. > > -- J. -- 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.
