Hi Patrick,
You could add parameters to the URL from an inner class inside the
RemoteService interface e.g.
public interface MyService extends RemoteService {
MyReturnValue aMethod(....);
/**
* Utility/Convinience class.
* Use MyService .App.getInstance() to access static instance of
IpsvRmapServiceAsync
*/
public static class App {
private static MyServiceAsync ourInstance = null;
public static synchronized MyServiceAsync getInstance() {
if (ourInstance == null) {
ourInstance = (MyServiceAsync ) GWT.create
(MyService.class);
// alter the URL here
((ServiceDefTarget) ourInstance).setServiceEntryPoint
(GWT.getModuleBaseURL() + "MyService");
}
return ourInstance;
}
}
However that is probably not such a good idea 'cos the session ID
would be visible on the wire.
A second ideas is to use a variation of the Command pattern which
might better be called Payload since it doesn't execute() anything
itself on arrival. Something like
public abstract class Payload implements Serializable {
private String sessionID;
public Payload() {
sessionID = someSessionIDCookieGrabbingMethod();
}
// or alternatively
public Payload(String sessionID) {
this.sessionID = sessionID;
}
public String getSessionID {
return sessionID;
}
}
Then if you then extend this to make individual RPC service parameters
(a sort of "bucket" for the objects you need to pass over for each
service call (although sometimes they are reusable for several calls)
you can cast them all to Payload in your override processCall and
examine and validate the sessionID before processing the call.
regards
gregor
On Nov 28, 11:52 am, 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
-~----------~----~----~----~------~----~------~--~---
