Anyway I'm a +1 for the new auth framework, I think it give us more power AND simplicity. Will it need improvement over time? of course it will but I think it's a much better base to work from.
Inline On 2/05/2009, at 9:45 AM, Adrian Crum wrote:
--- On Fri, 5/1/09, Andrew Zeneski <andrew.zene...@hotwaxmedia.com> wrote:What changed is that now the permission logic is NOT tied directly to the service itself. The logic is tied to the permission. So ANY call to authz.hasPermission() the EXACT same code runs that checks the permission. That is the single point of contact, the hasPermission() method. The checks in the screen definition runs the same code as the checks in service definition. So now one advantage is, the update or delete button which is displayed in the UI if the user has permission will display (even if they do not have the static permission associated with their account) if the user can edit that specific item. It won't display for other items which the user cannot modify.I must be missing something. Still using the Example component as an example: the service definition called a service permission, which called a script, which ultimately called Security.hasPermission. Your modification has the service definition use the <required- permissions> which ultimately calls authz.hasPermission(). So, both methods end up calling a single hasPermission() method. What changed?The only difference I see is that the permission string moved from a script to the service definition. Is that the desired benefit?
I think it's an improvement, you can directly see what permissions are required on the service without having to find a service def and then it's method. The newer permissions are more intelligent so you don't need to write a service for every variation in auth requirements.
3. Avoid having to check multiple permissions, forexamplePARTYMGR_UPDATE or PARTYMGR_ADMIN. Instead we usea newpermission format which embeds all permissionswhich will beaccepted:I don't see that being done explicitly in ourcurrent code. The OFBizSecurity class does that automatically. Any permission check is done with the ADMIN permission first, then the requested permission. Okay, so that was a bad example. How about CATALOG_UPDATE or CATALOG_ROLE_UPDATE instead as an example. Instead a simple permission defined as update:catalog:${catalogId} would take care of both of these. If the user has the static 'update:catalog' permission it would be granted (like a catalog admin might have), otherwise it would run the DA logic to determine if the user has permission to update that specific catalog.The idea of specifying some kind of parameter in the permission is interesting. The question is, (speaking as a user) What does that parameter do?
It runs dynamic access script defined on the SecurityPermission record
4. Define permission for users, not admins.Instead oflooking for a static permission, set thepermission to bechecked at the most granular level. When doing so,adminusers will always have permission and the API willhandleuser access using DA logic.I disagree. I might want my application to behavedifferently if an admin is using it. Without an admin permission (or attribute), how will I know if a user is in an admin role? Then we will create an 'admin' base permission. I didn't see the need for it, b/c I can't think of anything in which I would say "don't show this to people who can access/create/read/update/delete; only show it to an admin". I have nothing against this, just couldn't think of any really useful cases. Do you have something specific in mind?Maybe that could be expressed as :component:admin.
I would rather hear an example of what this would be used for before figuring out how to add it.
smime.p7s
Description: S/MIME cryptographic signature
