Hi Jens, we've had some similar question in a different context: how to determine the first request per place.
our idea is pretty simple, therefore i guess its a good one ;) (we're using restygwt, so my terms might differ somehow from the native gwt- rpc): * requestdispatcher is a placechangehandler * on placechange, the requestdispatcher changes some state and will attach an additional request header to the backend when performing the first call after that placechange. of course this header may contain some information about the placename.. * if this request responds with a 40x (or with an 40x with an additional response header), the requestdispatcher may trigger an application-event * based on that event, you can start another activity (e.g. an overlay), telling the user that there is a problem with its privileges what do you think about that idea? cheers, andi On 5 Jun., 17:05, Jens <jens.nehlme...@gmail.com> wrote: > Hi, > > during place integration I was thinking about activities and > authentication/authorization. Authentication seems pretty easy as its done > outside the whole places/activities framework but what about authorization? > > Lets say someone has bookmarked an URL like /#/editcustomer/123 because this > person frequently updates customer 123. Now the administrator changes > permissions and this person can not edit this customer anymore. It would be > nice if the person will see a "not authorized" dialog box and once he hits > OK then will be redirected to /#/customer where he can choose a different > customer if he wants to. > If the web app has only one display area/activity mapper it seems fine to > put the authorization code into the activity and let this activity show the > dialog box. But what if the app has more than one display area and thus more > than one activity that will be started? As activities more or less work on > its own each activity that needs the customer 123 would do the authorization > check on its own (which would result in more RPC requests instead of just > that single one that is needed) and its hard to say who should show the "not > authorized" dialog box. > > It would be nice if the place itself would already contain the information > if the logged in user account is allowed to access customer 123. That way > the activities could just stop (or better never really start) if the place > would contain such authorization information. > It would also be nice if a 3rd instance would be responsible for showing the > "not authorized" dialog box and handle the redirect to /#/customer. So > basically I want as much authorization code outside of activities...similar > to authentication which is done also outside activities. > > Is there any way to achieve this? > > How do yo handle such authorization with the places/activities framework? > > Thanks, J. -- 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.
