GWT: authentication for some part of the application using the GWT login page

My application has some features that are available to all users, and some other features that should only be restricted to authenticated users. All these limited functions exist within a certain set of GWT places, therefore all Places available in the application can be divided into two groups: "Accessible to all" and "Limited". In my opinion, places with limited access can implement some interface (let them say that it will be RestrictedAccess ), and if the user goes to one of them and has not yet been authenticated, he will be redirected to the login screen - this is more OO- approach than using URL filters.

I am trying to achieve:

  • Information about whether the user has been authenticated or not. stored on the server (this is not something that can be stored in a cookie ...)
  • The login page is the standard place for GWT + view + activity (!)
  • Username and password verification is done on the server side.

So far, I have introduced the RestrictedAccess interface, which is implemented by some set of places. My implementation of FilteredActivityMapper.Filter , which is passed to the FilteredActivityMapper application activity handler, has the following logic:

 Place filter(Place place) { if (place instanceof RestrictedAccess && !userHasBeenAuthenticated()) { return new LoginPlace(); } // return the original place - user has been already authenticated or // place is accesible for all users return place; } private boolean userHasBeenAuthenticated() { // remote call - how to do ??? } 

The problem is with the userHasBeenAuthenticated() method (the user should not be redirected to LoginPlace if it has already been authenticated). If I want to store this information on the server side, I need to make a GWT RPC / request factory call here, but both of them are asynchronous, so I cannot work with its result in the filter method.

I know that I can use web.xml filters or some external infrastructure (for example, spring security), but none of these approaches allows me to have a login page as a standard form based on GWT or to specify in more OO that access to a specific place should be limited.

Thanks in advance for any tips.

EDIT . I began to wonder if the filtering of places (limited / not limited) should generally take place on the client side. If, as suggested, there is an opportunity to hack a code indicating whether the user has been authenticated or not, there is also an opportunity to hack the site filtering code so that you can access limited places without logging in.

+4
source share
2 answers

Piotrek,

I think that there is a security problem when calling userHasBeenAuthenticated () - one could crack the client-side code to return true every time this function is called.

The solution I executed was to simply return SC_UNAUTHORIZED if an unauthenticated user tries to access the remote service. I overridden the RequestFactory onResponseReceived function, which redirects to the login page if the response is SC_UNAUTHORIZED. Idea taken from: http://code.google.com/p/google-web-toolkit/source/browse/trunk/samples/expenses/src/main/java/com/google/gwt/sample/gaerequest/client/ GaeAuthRequestTransport.java

This works for our situation when operations and locations are all data-oriented - each change in location retrieves data from the server. If the user is not authenticated, he simply does not receive the data and is redirected to the login page.

I understand that your situation is slightly different in that some places are accessible to everyone, in which case you can configure only limited services to return SC_UNAUTHORIZED.

+3
source

I have a similar application with the same requirements. Until I got to the point of implementation, but I was thinking about it.

What I planned to do was save the client side of the authentication state in the AuthenticationManager class. When the application starts, Iโ€™m going to request registration information from the server (I thought about starting on the application engine to get the authentication status, as well as get open login / logout URLs) and save it in the AuthenticationManager. Acegi / Spring Security runs on simlar, so this information is available on the server side if you use them too.

When a user logs in, he will be redirected by the server and the new state will be restored. This should maintain the state of client authentication in accordance with the server. Each RPC request on the server must also be authenticated. I used the gwt-dispacth library, and it has some rudimentary authentication and cross-site script protection too (although I think the latest GWT has this for general RPC).

One problem is the session timeout. Again, the gwt-dispath library has some code that detects this and returns expired exceptions for the client that may be caught, and the auth manager is updated.

Hope this makes sense.

+2
source

All Articles