Thanks Sri. That makes complete sense. I'd totally forgotten about CSRF. On Dec 29, 11:12 am, Sripathi Krishnan <sripathi.krish...@gmail.com> wrote: > > *Also, in the discussion I saw about this, it was said that it was > > more secure to send the session ID in the RPC itself instead of getting > > it from the header/cookie. Why is this? Does GWT add something extra like a > > hash to make sure the RPC hasn't been tampered with?* > > * > * > *GWT doesn't do anything special with RPC to make it tamper-proof. * > > The cookie is treated specially by the browser. The browser will > automatically send the cookie to the server regardless of any client or > server code explicitly asking for it. If you rely blindly on it, your code > will be susceptible to CSRF attacks. > > A header cannot be manipulated easily. If you "double-submit the session id" > - once in a custom header and once in the session cookie - and then compare > that both the ids are same - you prevent CSRF. If you prefer, you can also > send the header as a GET parameter. > > But why maintain the session id in the cookie if it is such a hassle? > Because that way you can leverage your application servers/frameworks > inbuilt session handling mechanism. There is no point in re-inventing the > wheel. > > If you haven't done so, please read GWT > security<http://groups.google.com/group/Google-Web-Toolkit/web/security-for-gw...>to > understand why this "double submit session id" approach works. > > For code, see notes below - > > *Client Side* > > 1. RPC async interface implements ServiceDefTarget. Using this interface, > you can set a custom RpcRequestBuilder > 2. In your custom RpcRequestBuilder, override the doCreate() call > super.doCreate() and get an instance of RequestBuilder > 3. Once you get the instance of RequestBuilder - add a custom http header > via the setHeader() method. The value of this header would be the session > id. > 4. See code below - > > //In a global file > public static final RpcRequestBuilder global_rpc_request_builder = new > RpcRequestBuilder() { > �...@override > protected RequestBuilder doCreate(String serviceEntryPoint) { > /* > * This RequestBuilder is used to make a RPC request > */ > RequestBuilder builder = super.doCreate(serviceEntryPoint); > builder.setHeader("SESSION_ID", getSessionIdFromCookie()); > return builder; > > } > }; > > //Before invoking RPC method > GreetingServiceAsync greetingService = GWT.create(GreetingService.class); > ((ServiceDefTarget)greetingService).setRpcRequestBuilder(global_rpc_request_builder); > > //Now invoke the RPC method > greetingService.greetServer("Hello World", callback); > > *Server side* > This is straightforward - read the header from the request object, and > compare the session id in header with the one you get from the session > cookie. > > --Sri > > On 29 December 2010 21:01, Falcon <msu.fal...@gmail.com> wrote: > > > Also, in the discussion I saw about this, it was said that it was more > > secure to send the session ID in the RPC itself instead of getting it > > from the header/cookie. Why is this? Does GWT add something extra like > > a hash to make sure the RPC hasn't been tampered with? > > > On Dec 29, 9:24 am, Falcon <msu.fal...@gmail.com> wrote: > > > I'm trying to send the session ID with every RPC request my GWT > > > application makes and handle our login context. On the server, it > > > looks like you can handle that by overriding > > > onAfterRequestDeserialized() and onAfterResponseSerialized() (we don't > > > need to add any information to the outgoing payload, just destroy the > > > login context, so we can do this after serialization). > > > > However, I'm not sure what I need to override on the client since > > > RemoteService is just an interface. I know GWT is doing some magic > > > with GWT.create(). Ideally, I'd like to extend RemoteService with a > > > new class, then extend that new class for all of my RPCs that needed > > > to send the session IDs automatically and then put the session ID > > > somewhere in the payload before the RPC was serialized to send across > > > the wire to the server. This just seems to make more sense to me than > > > having the session ID be a part of every single RPC method signature. > > > > Any help would be appreciated! Thanks! > > > -- > > 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-tool...@googlegroups.com. > > To unsubscribe from this group, send email to > > google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/google-web-toolkit?hl=en.
-- 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-tool...@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.
