[seam-dev] lost functionality in rule-based permission checks

[Dan Allen]

Yeah, I see where you are coming from. It's definitely possible in the
new model. It's just a different way of thinking about the problem.
It's also simpler because one of the dimensions has been removed,
which is likely a good thing. Regardless, we need to document this in
seam21migration.txt and in the security chapter. I'll add a JIRA
tomorrrow if you don't beat me to it. I will cite a couple of examples
there so people understand the before and after picture.

-Dan

On Tue, Nov 11, 2008 at 1:37 AM, Shane Bryzak <shane.bryzak at jboss.com> wrote:
> In this particular example, I see the Course instance as being the target of
> the permission check.  So if you want to check that you have permission to
> edit that course, the permission check would simply be:
>
> s:hasPermission(courseHome.instance, 'edit')
>
> If in addition to this you want to check that the user has permission to
> render the actual view, then you would use two permission checks:
>
> s:hasPermission(courseHome.instance, 'edit') and
> s:hasPermission('/CourseEditor.xhtml', 'render')
>
> Dan Allen wrote:
>>
>> Hmmm.
>>
>> Okay, let's go with the example. Let's say that I am going to edit a
>> record. In this case, the name of the permission check would be the
>> view ID, something like /CourseEditor.xhtml. The action would be
>> 'render' since this is happening before the page is rendered (though I
>> would likely have one for 'restore' too). Finally, we need to consider
>> the record which is being edited.
>>
>> s:hasPermission('/CourseEditor.xhtml', 'render', courseHome.instance)
>>
>> Now, I guess it would be possible to transpose this call into the Seam
>> 2.1 model as follows
>>
>> s:hasPermission(null, '/CourseEditor.xhtml:render', courseHome.instance)
>>
>> It's a bit odd that the name and context object are being swapped
>> inside the method because it makes for an awkward placement of null in
>> this case.
>>
>> I'm not convinced that everything is solved, but I can tell you that
>> we are going to need to document the migration. For people who have a
>> lot of rules in 2.0, they may have to do a fair amount of transposing
>> to make them fit in 2.1.
>>
>> -Dan
>>
>> On Tue, Nov 11, 2008 at 1:10 AM, Shane Bryzak <shane.bryzak at jboss.com>
>> wrote:
>>
>>>
>>> Unfortunately that would break the PermissionResolver interface, and the
>>> meaning of what a Permission is has been well defined in Seam 2.1.0 (for
>>> the
>>> better).  Can you give me an example of one of these permission checks
>>> and
>>> the corresponding rule?
>>>
>>> Dan Allen wrote:
>>>
>>>>
>>>> Shane,
>>>>
>>>> It appears that when the migration was made to the chain of permission
>>>> resolvers in Seam 2.1, the ability to place arbitrary objects into the
>>>> Drools working memory was lost. Before Seam 2.1, a permission check
>>>> consisted of a name, an action, and an unbounded set of contextual
>>>> objects. In Seam 2.1, only the first optional argument is considered,
>>>> and it's inserted into the working memory in place of the name.
>>>>
>>>> public boolean hasPermission(String name, String action, Object...arg)
>>>> {
>>>>  ...
>>>>  if (arg != null)
>>>>  {
>>>>     return permissionMapper.resolvePermission(arg[0], action);
>>>>  }
>>>>  else
>>>>  {
>>>>     return permissionMapper.resolvePermission(name, action);
>>>>  }
>>>> }
>>>>
>>>> I have quite a number of rules that rely on both the name and the
>>>> extra parameters. I'm sure others do as well. Can we change this logic
>>>> so that the permission mapper preserves the ordering of arguments and
>>>> the RuleBasedPermissionMapper stuffs the optional arguments into the
>>>> working memory?
>>>>
>>>> -Dan
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>
>



-- 
Dan Allen
Software consultant | Author of Seam in Action

http://mojavelinux.com
http://mojavelinux.com/seaminaction

NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters.  Please don't hesitate to resend a message if
you feel that it did not reach my attention.