I would also like to know...
Found this in the reference doc:
This annotation marks
the field or method
indicating whether the
role is conditional or
not. Conditional roles
are explained later in
...but I didn't find any further explanation later in the chapter.
Finally, for allowing our friends to view our images we need to have a special rule. Earlier we saw how it was possible to grant permissions to the role 'friends', however depending on the context 'friend' can have different meanings. Arguably, every single user in the system can be a 'friend' to someone else, so how do we determine who is a 'friend' when it comes to viewing images? This is where conditional roles step in - these roles are are special, and cannot be explicitly granted to users.
When a permission check is performed by the security API for an object and the permission manager informs the security API that a conditional role has been granted the permission, a special rule-based check needs to be performed to evaluate whether the current user actually has that role, but only within the context of the permission check. To achieve this, as per usual a PermissionCheck object is inserted into the working memory containing the target and action, however in addition a RoleCheck object is also inserted, containing the name of the conditional role that is to be evaluated. Using this we can write a security rule to determine whether or not to grant the conditional role:
rule FriendViewImage no-loop activation-group "permissions" when acct: MemberAccount() image: MemberImage(mbr : member -> (mbr.isFriend(acct.member))) PermissionCheck(target == image, action == "view") role: RoleCheck(name == "friends") then role.grant(); end
This rule checks whether the currently authenticated user is in the list of friends for the target image's owner. If it is, then the role is temporarily granted for this particular permission check. This allows great flexibility in assigning complex security rules to dynamic groups of users (in this case, a user's friends list) that don't necessarily warrant having their own role/group, due to either impracticality or design restrictions.