I am using the straightforward Service/AsyncService on client side and ServiceImpl on server side. I will probably walk through your source code for a better understanding.
Will probably follow the deferred binding concept in the widget authorization part.
Thanks and Regards,
Asif
On Thursday, July 25, 2013 7:43:11 PM UTC-4, Thomas Broyer wrote:
--From experience, managing login in the app without reload makes it much harder and quickly become a PITA. Redirecting to a login page that redirects back to the app (causing a reload, i.e. start fresh) is much easier to handle, so unless you really need "login without reload" (e.g. user starts action but can only complete it if he's logged in, and you don't want him to lose its data by redirecting it and reloading the app fresh after authentication; but localStorage can help here, or even a cookie for older browsers), don't use it.I then use a dynamic host page to pass data about the user to the app (username, roles, etc.)On the server-side, use an AOP approach, with annotations on your services and service methods (use true AOP with RPC, possibly through Guice; use a ServiceLayerDecorator for RequestFactory). Return a 403 Forbidden when the action is not allowed for the current user (or use a custom exception in RPC, if you can), a 401 Unauthorized (without WWW-Authenticate header, or with a "fake" challenge if you don't want to violate the "401 mandates WWW-Authenticate" rule of HTTP) when the user is not logged in; and catch those on the client-side (preferably in a central place; RequestFactory's RequestTransport is great for that, use an RpcRequestBuilder or an AsyncCallback super-class for RPC).You can see an example in my Maven archetype (only covers authentication, not authorization; I need to make my authorization ServiceLayerDecorator public at some point, already duplicated it in a couple projects): https://github.com/tbroyer/gwt-maven-archetypes/ tree/master/guice-rf- activities/src/main/resources/ archetype-resources/ Also I want to use widget level authorization - depending on the authorization of logged in user , widgets are made visible or invisible etc - so looking for a very fine grained authorization framework.My approach so far was purely programmatic (equivalent to isUserInRole from servlets, but on client-side). With good accessors, you can even use it directly as visible="{roles.abc}" in UiBinder (at the expense of building the widget even if the user doesn't use it, so use sparingly). Not very productive, sometimes cumbersome, but you have complete control.An alternative (feel free to mix and match different approaches) is to use deferred binding to have one permutation per "role", and use a <property-provider> to select the appropriate permutation at runtime, depending on some data put on the host page by the server (dynamic host page once again).
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
No comments:
Post a Comment