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

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(a)jboss.com&gt; 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(a)jboss.com&gt; >> 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 >>>> >>>> >>>> >>>> >>> >> >> >> >