4 Replies Latest reply on Jan 23, 2008 6:18 PM by Shane Bryzak

    roles redirecting methods

    Zied Hamdi Newbie

      Hi,

      I'm learning Seam and its role extended features. It's a very big step compared to JAAS but I recognize I expected a more adapted behavior :-/

      In fact, the code is always full of test cases that redirect to the corresponding method for a given role if( "role1" ) doThis(); else doThat(); to return a restricted result list or simply overdrive a deature againt the role.

      I was suprised Seam didn't adress this common concept, even more because I was very pleased by the other aspects of Seam, espacially conversations.

      The idea I imagined to solve code repetition for role testing was sth like an intercepted method :

      @RoleSensible
      void myMethod() { //do common tasks };


      then intercepting methods e.g:

      @RoleCase( method="myMethod" )
      @Restricted("#{s:hasPermission('bean', 'case1', user)}")
      void case1() {};
      


      the annotation I imagined @RoleSensible should be mandatory, even it's just there only to warn the method will be intercepted.

      Do I have to add a feature request? or maybe is it not in the spirit Seam was designed in?

      Regards,
      Zied hamdi

        • 1. Re: roles redirecting methods
          Shane Bryzak Master

          Sorry I really don't understand what you're asking.

          • 2. Re: roles redirecting methods
            Zied Hamdi Newbie

            Hi Shane,

            Sorry if my last mail wasn't clear. I'll explain the idea by the mean of a frequent example:

            Let's imagine we have an application with 3 rules: client, commercial and administrator : the client can see only its orders, the commercial can only see the orders of his clients and the administrator can see all orders:

            This example can only be developed like this :

            doCommonCode();
            if( rule="commercial" ) {
             doCommercial();
            } else if( rule="client" ) {
             doClient();
            } else if( rule="administrator" ) {
             doAdministrator();
            }


            The new seam authorization mecanism cant' do this simply beacuse the @Restricted annotation is binary (not a switch). These if else blocks become very frequent and reduce code readability.

            The solution I sent is just a proposition: It attempts to add to the annotations the responsibility to redirect to the business rule case method. Here's how I imagine it:

            @RuleSensible comes as the @Override annotation : it just enforces readability and code changes safety : it informs this method is a rule switch. (inside the method body comes the common code to all cases)

            @RuleCase( method="switchMethodName ) is there to say : this is a switch case for the given method

            and finally @Restricted comes to say which rule case must be handled by the annotated method.

            So here was my idea, I hope you'll like it.

            • 3. Re: roles redirecting methods
              Zied Hamdi Newbie

              Hi Shane,

              Maybe I should enumerate the benefits I see in this approach:


              +Suppress redundant (and error prone) information when you redirect programatically to a rule specific method (that you also enforse with a @Restricted with the "already tested" rule)
              +Modeling tools will be able to reverse engineer "per rule" sequence diagrams
              +Builders can remove all non relevant methods in a given subproduct configuration


              • 4. Re: roles redirecting methods
                Shane Bryzak Master

                Ok, I think I finally understand what you're saying. Unfortunately no, we won't be implementing anything like this, from what I can see it will complicate the security model tremendously without any substantial benefit. Your example use case of filtering orders by role can easily be achieved with entity security and a rule-based permission.

                If you have another use case that isn't currently supported by the existing security features then please let me know, and we'll see if it can be addressed in some other way.