ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Crum <adrian.c...@yahoo.com>
Subject Re: Authz API Discussion (was re: svn commit: r770084)
Date Fri, 01 May 2009 20:23:56 GMT

--- On Fri, 5/1/09, Andrew Zeneski <andrew.zeneski@hotwaxmedia.com> wrote:
> From: Andrew Zeneski <andrew.zeneski@hotwaxmedia.com>
> Subject: Authz API Discussion (was re: svn commit: r770084)
> To: dev@ofbiz.apache.org
> Date: Friday, May 1, 2009, 10:36 AM
> 1. Single point of contact for ALL security checks, instead
> of having security embedded in functionality, or tied to
> services directly, the API should be the governor of all
> security. This means no more writing security logic in the
> functionality, and no more permission services attached
> directly to functionality (services or ecas). This is a bad
> design IMHO because it spreads the permission logic around
> in multiple places and makes it impossible to get the same
> results when checking permissions from different framework
> tools.

I don't understand what this means. Looking at the changes you made in the Example component,
you still have permissions tied to the service definitions. Then you have permissions being
checked in the screen widgets. From my perspective, nothing changed except the format of the
permission string. Where is the "single point of contact" in the Example component?

> 3. Avoid having to check multiple permissions, for example
> PARTYMGR_UPDATE or PARTYMGR_ADMIN. Instead we use a new
> permission format which embeds all permissions which will be
> accepted:

I don't see that being done explicitly in our current code. The OFBizSecurity class does that
automatically. Any permission check is done with the ADMIN permission first, then the requested
permission.

> 4. Define permission for users, not admins. Instead of
> looking for a static permission, set the permission to be
> checked at the most granular level. When doing so, admin
> users will always have permission and the API will handle
> user access using DA logic.

I disagree. I might want my application to behave differently if an admin is using it. Without
an admin permission (or attribute), how will I know if a user is in an admin role?

-Adrian



      

Mime
View raw message