Re: Authz API Discussion (was re: svn commit: r770084)

[Scott Gray]

Inline

On 2/05/2009, at 10:45 AM, Adrian Crum wrote:

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.

Appearances must be deceiving, to the best of my knowledge Andrew put a lot of effort into creating a proposal, posted it to confluence and created a jira issue linking to the page (which got sent to the dev list). He then responded to all the comments that people made, waited a few days for additional comments and THEN began coding.

My recommendation would be to reboot this entire process to give the community a chance to be involved in the design.

What do you mean by reboot this entire process? So far you're the only person who has questioned the design... and you already commented on it initially on the confluence page to which Andrew responded.

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.

I agree this could have been done more explicitly but a jira issue was created which does get sent to the dev list. People obviously saw it because comments were posted to the page.

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.

I don't understand why you don't understand, how is what has been committed different from the detailed design proposal that Andrew posted last week? I now realize you've obviously read it because you commented on the page, so if you don't understand what is being done now then you mustn't have understood it last week either and if you didn't understand it last week why didn't you post more comments/ questions?

-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

smime.p7s
Description: S/MIME cryptographic signature