Don't get me wrong, I'm not resisting change. I commented on your design
document that I'm in support of a security refactor. I'm sure others in the
community would support that too.
The problem is, this wasn't discussed with the community beforehand. No one was
given an opportunity to provide input. It appears (and I know that this might
not be true) that the design was created, some coding had been done, and THEN a
document was drawn up and code committed shortly afterward.
My recommendation would be to reboot this entire process to give the community
a chance to be involved in the design.
We should:
1. Send an email to the dev mailing list (and optionally the user list) asking
for comments on the existing security framework and what they would like to see
changed.
2. Compile the list into a set of design objectives.
3. Send the list to the dev mailing list and ask for suggestions for
implementing the design objectives.
4. Compile a list of implementations and send it to the dev mailing list for a
vote.
>From my perspective, that's how a developer community should work. Until those
>steps are followed, you're going to have a lot of people asking the same
>questions I am - because they weren't involved and don't understand what
>you're doing.
-Adrian
--- On Fri, 5/1/09, Andrew Zeneski <andrew.zene...@hotwaxmedia.com> wrote:
> From: Andrew Zeneski <andrew.zene...@hotwaxmedia.com>
> Subject: Re: Authz API Discussion (was re: svn commit: r770084)
> To: dev@ofbiz.apache.org
> Date: Friday, May 1, 2009, 2:30 PM
> Don't worry, I expected some level of resistance to a
> change of this magnitude, plus this requires a very
> different way of thinking so I planned on having to explain
> it, I tried to cover everything in the document, but
> that's impossible to do :)
>
> This is VERY similar to the existing security
> implementation, and very similar to other security APIs out
> there (JSecurity, Spring Security, etc). The slight
> differences are:
>
> Easier to understand and follow. Reading the new permission
> string format, you can see what is being checked. Nothing is
> hidden. The logic used to determine granular access control
> it defined on the permission itself. No more guessing where
> permission logic is located.
>
> It is much easier to extend, create seed data which
> overwrites the default permission logic references and use
> your own custom logic to determine access. No need to
> override service definitions or patch code (well once the
> migration is complete) or comment out ECAs.
>
> So, now my questions for you are: What is missing? What
> does this new API NOT do, which you are looking for?
>
>
> Andrew
>
>
> On May 1, 2009, at 4:37 PM, Adrian Crum wrote:
> >
> > I read the Auto-Grant section. The question is, where
> is the seed data shown in your code example located? If
> it's it the SFA component, then the permissions are
> still spread around. All that has changed is instead of
> having permission-modifying SECAs in components, you have
> permission-modifying seed data in components. How was
> anything "centralized?"
> >
> > I don't mean to pour cold water on your
> enthusiasm, it's just that I don't see where
> anything is being added or improved. It looks basically the
> same, only slightly different.
> >
> > -Adrian
> >
> >
> >
> >
