Re: Best way to handle authentication failures with RequestFactory on the client

You can define a custom event for authentication failure and register a handler for it at startup. That is the approach taken here:

http://code.google.com/p/google-web-toolkit/source/browse/trunk/samples/expenses/src/main/java/com/google/gwt/sample/gaerequest/

A handler for the GaeAuthenticationFailureEvent is registered in the module entry point (ExpensesApp.java):

    // Check for Authentication failures or mismatches

    new ReloadOnAuthenticationFailure().register(eventBus);

An alternative approach is to extend the Receiver class with your own version that implements onFailure:

public abstract class MyReceiver<V> extends Receiver<V>

{

@Override

public void onFailure(ServerFailure error)

{

Location.replace(LOGIN_URL);

}

}

Anywhere you fire a request, pass MyReceiver instead of Receiver.

HTH,

/dmc

On Wed, Feb 23, 2011 at 4:56 AM, juanita <juanita.vollmering@googlemail.com> wrote:

I am trying to figure out the best way to handle authentication
failures with RequestFactory on the client.

The way I understand this is supposed to work is as follows:
The client will perform a server request - typically expecting data to
be returned. The gwt framework will check if the user is authenticated
before passing the request to the corresponding class. The default
implementation basically returns true, a custom implementation of
UserInformation would perform the actual check.
If the gwt framework finds out that the user is not logged in, the
request will not be processed but a failure message is sent back to
the client.
The client would know that something is wrong, since onFailure()
rather than onSuccess() is called on the client.

This piece is working fine for me so far.

However, I am struggeling with finding a proper way to handle
authentication failures on the client. Typically, there is a large
number of places in the client code that perform server requests.
Having to inject the onFailure() code at each place to check for an
authentication failure and then act the same way (basically redirect
to a login url) seems to be inappropriate.
Is there a better way to intercept and handle these in a single
location?

--
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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
David Chandler
Developer Programs Engineer, Google Web Toolkit
w: http://code.google.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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.