@Reinier
> 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. Suppose I replaced: sessionID = someSessionIDCookieGrabbingMethod(); with: sessionID = someReinierApprovedEncryptionAlgorithm(); would this meet with your approval? If not can you explain why? regards gregor 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 [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 -~----------~----~----~----~------~----~------~--~---
