The solution is simple: Rewrite the session management part of your web stack so that it doesn't look at the cookie (it should completely ignore the cookie - it is there only to let the session survive when the user reloads the page / closes their browser), instead lifting the session out of the parameters. You don't need to remove it, really - any framework or servlet engine that gives unfettered access to the parameters also gives unfettered access to the cookies, so there's no point.
gregor: What do you mean 'bad idea because the session ID would be visible on the wire'? All session IDs are visible on the wire, unless you set up a scheme where the client javascript does some hashing or encryption. It's been floated as an idea many times on this forum, and it is certainly feasible, but its very much outside of the norm. Virtually nobody on the entire web is doing this today. There are a number of issues I don't really want to get into. Suffice to say: Yes, doable. Yes, very cool. No, not standard or required by any stretch of the imagination. Such a scheme would still be significantly less secure than SSL, because it won't hold up to a man in the middle attack (the man in the middle will just modify your GWT code to send the password to his secret server in nigerussomania. On Nov 28, 12:52 pm, Patrick Ratelband <[EMAIL PROTECTED]> wrote: > Hey everyone, > > I have been working a while now on properly defending my GWT app > against Cross Site Request Forgery (XRSF) with a minimal change in the > code of the application itself. > > My idea has been to create a new RPC call that will be the same from > the programmers points of view as the normal, but which will add some > value (a sessionID for instance) to the list of supplied parameters > just before the call is send. Then, on the server side, the programmer > would extend the SecureRemoteServiceSevlet (SRSS) instead of the > normal one. This secure version will simply remove the extra > paramater, check it's validity and only execute the requested method > if the authentication succeeds. > > So far I have been able to subclass the RemoteServiceServlet (RSS) > into the SRSS. It overrides the processCall(String payload) method to > implement the verification (in my case the last argument, but that can > easily be changed), thus working exactly the same as the normal RSS > without any change needed in the code other than changing the extend. > > The problem is that I really do not understand where I might add the > code to modify the sending of the request client side. I have studied > the RPC diagrams and almost everything I could find on the group > concerning RPC, but I still do not understand what I need to change or > override to create a custom RPC call. I have thought about making a > subclass of the ServiceDefTarget so that the calling URL could be > modified, but this is an interface and not a class, so is not going to > work. > > Does anyone have any idea's on this? > > Patrick > > PS: If I succeed at making something useful, I will create a package > and a tutorial to share my knowledge. No need to reinvent the wheel. --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
