> > *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-gwt-applications?pli=1>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.
