It depends on what you specify as your token in XsrfTokenServiceServlet (see
the Javadoc). If you use JSESSIONID, then you would need sticky sessions or
session replication as with any use of server sessions.
/dmc
On Tue, Jul 12, 2011 at 7:13 AM, batosai <tariq.albabt...@gmail.com> wrote:
> What would happen in the case of a load balancer and rpc requests
> switching from one server to another from the same client , is sticky
> sessions required ?
>
> On Jul 6, 4:32 pm, David Chandler <drfibona...@google.com> wrote:
> > Hi Joey,
> >
> > The XSRF token is stateless so you only need to call the XsrfTokenService
> > once per server session to obtain it. You can save it as a static
> variable
> > in a service helper class. Thereafter, you just need to call setRpcToken
> for
> > each service.
> >
> > Some projects GWT.create() all services in a helper or factory class like
> >
> > public class ServiceHelper {
> >
> > private static SomeServiceAsync someService;
> >
> > static {
> > (SomeServiceAsync) someService = GWT.create(SomeService.class);
> >
> > }
> >
> > public static getSomeService() {
> > return someService;
> >
> > }
> > }
> >
> > If you do this, you might initialize each service with the token when you
> > create it. Thereafter, client code can call
> ServiceHelper.getSomeService()
> > in order to make a request. For example, you could put the following in a
> > static initializer in the ServiceHelper to obtain the XSRF token when the
> > app loads:
> >
> > XsrfTokenServiceAsync xsrf =
> > (XsrfTokenServiceAsync)GWT.create(XsrfTokenService.class);
> > ((ServiceDefTarget)xsrf).setServiceEntryPoint(GWT.getModuleBaseURL() +
> > "xsrf");
> > xsrf.getNewXsrfToken(new AsyncCallback<XsrfToken>() {
> >
> > public void onSuccess(XsrfToken token) {
> > initSomeService(token);
> > initNextService(token);
> > ...
> > });
> > }
> >
> > As far as handling the XSRF exception centrally, you can wrap
> AsyncCallback
> > with your own class like XsrfProtectedCallback in which you implement
> > onFailure(). This is a good practice anyway in order to provide uniform
> > error handling for your RPC calls. See HupaCallback in the Apache
> HupaMail
> > project for an example of a wrapped callback.
> >
> > HTH,
> > /dmc
> >
> >
> >
> >
> >
> > On Wed, Jul 6, 2011 at 4:33 AM, Joey <huazong...@gmail.com> wrote:
> > > Hi All
> >
> > > I have a big GWT project, there are many services and methods need to
> > > be protected. but I think it a hard work to
> > > change all of code what call methods as the following code from google
> > > document. So just want to know anybody
> > > has any simple way can fix XRSF problem and no need to change so many
> > > code for methods calling.
> >
> > > -------------------------------------------------------------
> > > XsrfTokenServiceAsync xsrf =
> > > (XsrfTokenServiceAsync)GWT.create(XsrfTokenService.class);
> > > ((ServiceDefTarget)xsrf).setServiceEntryPoint(GWT.getModuleBaseURL() +
> > > "xsrf");
> > > xsrf.getNewXsrfToken(new AsyncCallback<XsrfToken>() {
> >
> > > public void onSuccess(XsrfToken token) {
> > > MyServiceAsync rpc = (MyServiceAsync)GWT.create(MyService.class);
> > > ((HasRpcToken) rpc).setRpcToken(token);
> >
> > > // make XSRF protected RPC call
> > > rpc.doStuff(new AsyncCallback<Void>() {
> > > // ...
> > > });
> > > }
> >
> > > public void onFailure(Throwable caught) {
> > > try {
> > > throw caught;
> > > } catch (RpcTokenException e) {
> > > // Can be thrown for several reasons:
> > > // - duplicate session cookie, which may be a sign of a cookie
> > > // overwrite attack
> > > // - XSRF token cannot be generated because session cookie
> > > isn't
> > > // present
> > > } catch (Throwable e) {
> > > // unexpected
> > > }
> > > });
> > > -------------------------------------------------------------
> >
> > > Thanks
> >
> > > Joey
> >
> > > --
> > > 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
> > > google-web-toolkit+unsubscr...@googlegroups.com.
> > > For more options, visit this group at
> > >http://groups.google.com/group/google-web-toolkit?hl=en.
> >
> > --
> > David Chandler
> > Developer Programs Engineer, GWT+GAE
> > w:http://code.google.com/
> > b:http://turbomanage.wordpress.com/
> > b:http://googlewebtoolkit.blogspot.com/
> > t: @googledevtools
>
> --
> 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
> google-web-toolkit+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>
>
--
David Chandler
Developer Programs Engineer, GWT+GAE
w: http://code.google.com/
b: http://turbomanage.wordpress.com/
b: http://googlewebtoolkit.blogspot.com/
t: @googledevtools
--
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
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
