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

[Shane Bryzak]

Sure thing, I actually thought I had updated seam21migration.txt but it 
seems I forgot to describe this change. 

Dan Allen wrote:
> 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
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>         
>>>
>>>
>>>       
>>     
>
>
>
>