Securing only part of the App

[msanztru]

Hello,

I have been struggling all day with an issue. I am sure there must be some easy solution that lots have already implemented as it looks to me as a basic setup.

I am building an app with GWT and appengine using requestfactory. This app has some "pages" (they are actually MVP views) that everybody should have access to. It's like the home page and a couple of views where the service we provide is described. Then if you want to use the service you have to login (with google accounts and all that). Only being logged in you have access to the rest of the views (pages) in the app. The question is, how to handle this?, the fact that some pages and some requestfactory calls are public and some other have to be available to those that have logged in?

I have already discarded the auth-constraints tags in web.xml because they work with all or nothing.

The next alternative was to use servlet filters (as the expenses demo does). That could work, but only if the "open" or not secured pages didn't need to access any data from appengine datastore (and I don't want to close that door, maybe in the future I want to show status or number of users, etc etc). The reason for this is that with request factory you only have one servlet so if you put a filter you shut down all comunication with appengine if the user is not logged in.

I was thinking of implementing this filter, with requesfactory for all the stuff once the user is logged in and also implement some RPC services for the data i might want to display in the "home or information pages" that i might need to retrieve from the datastore. However it looks a bit overkill for me.

Anyone had the same problem? any ideas?

I'd appreciate any help on this.

Thanks,

Miguel

[Thomas Broyer]

You could have 2 instance of RequestFactoryServlet: one "open", the other requiring authentication. On the client-side, use a RequestTransport to set the URL of the one servlet you want to use.

And in each and every service, check if the user is logged in (so that even if the service is accessed through the "open" end point, a user couldn't access unauthorized data).

The only difference between the two instances would be the way this is communicated to the client (so that it can be handled accordingly): with then "open" endpoint, onFailure of your Receiver would be called with the exception thrown by your service, whereas with the "secured" endpoint, the filter would send a specific response that the RequestTransport would handle.

Of course, you could even have a single, "open" endpoint, if you don't need the specific handling of lack of authentication (request blocked by a servlet filter, response handled in a RequestTransport; as in the Expenses sample).

[msanztru]

Thanks Thomas,

I have been thinking in your approach and others but so far yours looks like the more feasible one and is the one I will implement.

I thought about implementing a servlet filter where I would "decript" the request and see what was the target service and grant or deny acces depending if the user was logged in or not. But I couldn't figure out how to do it... (any ideas :)

Thanks for your help!!

[Thomas Broyer]

On Tuesday, September 20, 2011 9:21:14 AM UTC+2, msanztru wrote:

I thought about implementing a servlet filter where I would "decript" the request and see what was the target service and grant or deny acces depending if the user was logged in or not. But I couldn't figure out how to do it... (any ideas :)

Use a ServiceLayerDecorator where you override/implement the invoke() method.

FWIW, we put annotations on our service methods, and a ServiceLayerDecorator grants access to them after checking the current user's role against the one required to call the method (similar to @RolesAllowed in the JavaEE or JAX-RS world). In our app, the user has to be authenticated, so we have a servlet filter and RequestTransport much like in the Expenses sample). That wouldn't work well for anonymous access (if you let anonymous users in, then you cannot easily communicate back a lack of authentication), hence my proposal of using a different URL in that case (either you use the "open" end point, and an error could mean that you tried to call a method requiring authentication –that would be a bug in your app, or a potential attack–, or you user the "secured" end point and an error could mean that you tried to call a method requiring different privileges –again, that would probably mean a bug in your app, or a potential attack, or possibly that the privileges of the user have changed between the time the UI showed him the actions it could perform, and the time it actually performs them, but that's something you have to deal with in every client-server app; in our app, we cache the user's roles in the session, so that even if you change his privileges, they won't be taken into account until he logs out and in again–).