5 Replies Latest reply on Feb 16, 2007 6:08 PM by adsf adsf

    Question regarding Identity.hasPermission(...)

    adsf adsf Newbie

      I'm probably missing the obvious but according to the docs the check for s:hasPermission(...) is implemented in org.jboss.seam.security.Identity.hasPermission(...) but this method always returns false (CVS from today).

      So isn't this stuff implemented yet (I thought it was but I haven't used it yet) or is this a bug or where is the check actually performed or ... ???

        • 1. Re: Question regarding Identity.hasPermission(...)
          Gavin King Master

          Look in RuleBasedIdentity.

          • 2. Re: Question regarding Identity.hasPermission(...)
            adsf adsf Newbie

            As I said: I'm missing the obvious - thanks for enlightening me :D

            However, I have 3 more questions (regarding the security stuff in the seamspace example):

            1. the security-rules.drl requires - i.e. - a Member in the working memory: is it right that those objects are inserted into the working memory via s:hasPermission / RuleBasedIdentity.hasPermission(...) (the 3rd+ parameter) and they stay there only for one evaluation ?

            2. The PermissionCheck objects & the additional facts live in the working memory only for one evaluation - so if I have 2 permissions checks within 1 request that check for the same permission all the stuff is reevaluated a 2nd time ?

            3. The most important one: Why do you add "activation-group permissions" in the security-rules.drl file (the rules should be mutually exclusive because there is just one PermissionCheck in the working memory) ?

            • 3. Re: Question regarding Identity.hasPermission(...)
              adsf adsf Newbie

              Having played a bit with the security API I assume the answer on 1. & 2. is Yes - please correct me if I'm wrong.

              Regarding 3.:

              Why do you add "activation-group permissions" in the security-rules.drl file (the rules should be mutually exclusive because there is just one PermissionCheck in the working memory) ?


              Is the answer: If they don't belong to the same activation group the rules engine would evaluate the remaining rules (after it found a match) although they obviously would evaluate to false - so you put them in the same activation-group to ensure it doesn't waste its time ?

              • 4. Re: Question regarding Identity.hasPermission(...)
                Shane Bryzak Master

                 

                "spambob" wrote:

                1. the security-rules.drl requires - i.e. - a Member in the working memory: is it right that those objects are inserted into the working memory via s:hasPermission / RuleBasedIdentity.hasPermission(...) (the 3rd+ parameter) and they stay there only for one evaluation ?


                Yes, they only stay there for a single permission evaluation.

                "spambob" wrote:

                2. The PermissionCheck objects & the additional facts live in the working memory only for one evaluation - so if I have 2 permissions checks within 1 request that check for the same permission all the stuff is reevaluated a 2nd time ?


                That's right.

                "spambob" wrote:

                3. The most important one: Why do you add "activation-group permissions" in the security-rules.drl file (the rules should be mutually exclusive because there is just one PermissionCheck in the working memory) ?


                Strictly speaking you probably don't need this. I've just included it as a safety mechanism to ensure that only one of the rules will match (I previously had a catch-all rule to deal with role permissions, but these have been removed).

                • 5. Re: Question regarding Identity.hasPermission(...)
                  adsf adsf Newbie

                  Thank you Shane for clearing this up! I think I get it now :)