1 Reply Latest reply on Jun 17, 2013 2:10 AM by Erik Jan de Wit

    Stop @Page from showing

    John DeStefano Apprentice



      I'm working on an app where I need to show a @Page annotated view class only if the user has the appropriate rights. I looked at  the security example, and that looks interesting for cases where communications back to the server is necessary. I'm using 3.0-SNAPSHOT and a role class in the page annotation to have groups of pages that can be seen by a user who has a "role" that matches the page role. When the app starts I use the Navigator to query for all the @Page's and put them in a map, by name, that links to a specific user role. In the @PageShowing annotated method of the page class I compare the the current users role to the map to see if the user has appropriate rights to see the page. If not they are navigated to the page with the role class DefaultPage. This works, but it takes until just before the page is being shown to get to a point where I have all the information I need to evaluate. The GWTP framework has the concept of a GateKeeper to do something similar to what I'd like to do with page navigation in Errai. Has any thought been given to this type of feature?


      On the back end of my app I'm using DeltaSpike annotations to secure method invocations. I know some work has been done on interceptors on the client side. If client interceptors where available and could be used at the TYPE level, then a view class could be annotated with an annotation tied to an interceptor and navigation decisions made at that point.




        • 1. Re: Stop @Page from showing
          Erik Jan de Wit Novice

          Hi John,


          You could also use the secruty framework instead of the Page roles. The idea of the scurity framework is to add annotations on html elements and if the user doesn't have the appropriate role(s) these elements will be hidden from the view. So the link to the page that you don't want the user to see will be hidden for instance. Of course this is not enought to ensure that the user doesn't try to go to a page that he is not allowed to see, but you already have secured the server part so eventhough the user could call the page it would be a page without any data.



               Erik Jan