Big +1
But also I agree that Andrew made is best to communicate before commiting
For me 2 things were missing
1) A news on MLs, but it looks like Andrew sent one and it did not get through for a reason or another (things between head and
keyboard? ;o)
2) CTR mode : commit to fast before anybody had time to review anything
Jacques
From: "Adrian Crum" <adrian.c...@yahoo.com>
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
>
>
>
>
