4 Replies Latest reply on Oct 13, 2011 5:27 AM by piklos

    Question about AuthorizationCheckEvent.

    piklos

      Hello, i am using seam-security 3.0.0.Final (along with some other seam modules) on tomcat 7.


      I am trying to execute some code only if security checks have passed for certain page.


      I am trying to do it like this:




      public void observeAfterRestoreView(@Observes AuthorizationCheckEvent e) {
       if (e.isPassed())
           doAction();
      }



      But e.isPassed() is always false, regardless of the actual authentication. And this is why:


      Code in  SecurityPhaseListener.




       private void enforce(FacesContext context, UIViewRoot viewRoot, List<? extends Annotation> annotations) {
            if (annotations == null || annotations.isEmpty()) {
                 log.debug("Annotations is null/empty");
                 return;
            }
            AuthorizationCheckEvent event = new AuthorizationCheckEvent(annotations);
            authorizationCheckEvent.fire(event);
            if (!event.isPassed()) {
            .....


      Fires that event, but the passed property is false by default.


      Another observer of the same event actually sets passed property to true (if authorization criteria is set). That observer is called AuthorizationObserver.


      So because there is no way to specify which observer gets notified first there is actually no way to listen AuthorizationCheckEvent in a useful way. (On tomcat 7 it seems that my observer always gets called before the AuthorizationObserver)


      So couldn't there be a better soultion in this architecture than to use side affects on the payload on the authorization event?


      I know that in CDI you cannot specify the order in which the observers get notified, but couldn't you use additional events for different things that can happen during authentication?


      For instance whouldn't it be nice to have a new event that would get fired if authorization is ok?? (It could be called something like AuthorizationPassedEvent)


      And wouldn't it overall be a better design not to change the payload of the events in observers? In my view all events should be made immutable, and than stuff like this would never happen.


      Kind regards.




        • 1. Re: Question about AuthorizationCheckEvent.
          lightguard

          I would certainly create a JIRA for this one.

          • 2. Re: Question about AuthorizationCheckEvent.
            bleathem

            wouldn't it overall be a better design not to change the payload of the events in observers? In my view all events should be made immutable, and than stuff like this would never happen.

            The AuthorizationCheckEvent is used to loosely couple Seam Faces to Seam Security.  Toggling the passed is how the two modules communicate.



            For instance whouldn't it be nice to have a new event that would get fired if authorization is ok?? (It could be called something like AuthorizationPassedEvent)

            This is indeed the appropriate course of action.  Please file a jira requesting this addition.  (File it quickly to get it in in time for the upcoming 3.1 release!)

            • 3. Re: Question about AuthorizationCheckEvent.
              piklos
              • 4. Re: Question about AuthorizationCheckEvent.
                piklos

                What is going on with this jirra issue? It has been filed more that a month ago, and nobody seems to even noticed/commented/assigned it. To me it seems like a straight forward thing to do in order to increase the quality and usability of seam security module. Also it seems really easy to implement (just add new event, and document that the old one is not safe for usage).