You're asking me if some Reinier Approved algorithm would meet with my approval?
Uh, yes. I have a question for you, though: Does a gregor approved method of shooting a puppy meet with your approval? If not, can you explain why? On Nov 28, 9:02 pm, gregor <[EMAIL PROTECTED]> wrote: > @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 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 -~----------~----~----~----~------~----~------~--~---
