Remove Zend\Acl from 2.0, update and then add to 2.1?

[akrabat]

Hi all,


I've seen some discussion about Zend\Acl and whether it's the best it could be for ZF2.0 [1]. To the best of my knowledge, there's at least 3 modules that do their own Acl, presumably because Zend\Acl isn't good enough?

Does anyone have an opinion on whether it's good to go or whether we should pull it from 2.0, do an RFC, re-work it and then introduce for 2.1?


Regards,

Rob...


[1]: https://github.com/ZF-Commons/RFC/issues/1#issuecomment-7164039 - the thread is mostly about which Acl module should integrate with ZfcUser, but the comments on Zend\Acl is relevant.

[xoops]

+1

The Acl component has been already dropped from our project.

On Mon, Jul 23, 2012 at 2:38 PM, Rob Allen <[hidden email]> wrote:

Hi all,


I've seen some discussion about Zend\Acl and whether it's the best it could be for ZF2.0 [1]. To the best of my knowledge, there's at least 3 modules that do their own Acl, presumably because Zend\Acl isn't good enough?

Does anyone have an opinion on whether it's good to go or whether we should pull it from 2.0, do an RFC, re-work it and then introduce for 2.1?


Regards,

Rob...


[1]: https://github.com/ZF-Commons/RFC/issues/1#issuecomment-7164039 - the thread is mostly about which Acl module should integrate with ZfcUser, but the comments on Zend\Acl is relevant.

--

Taiwen Jiang (aka D.J.)

Build Xoops Engine

http://www.xoopsengine.org

web and mobile application platform

CTO for EEFOCUS.com

Leading social platform for electronics professionals

[bjy]

-1.

Three modules exist in order to simplify its usage. Here is a rough timeline: ZfcAcl came first, but a lot of people found it difficult to extend. SpiffyJr started writing SpiffySecurity, then decided he wanted to go with an RBAC solution instead of ACL. As a response, I went ahead and wrote BjyAuthorize which is based ideas from both SpiffySecurity and ZfcAcl.

I don't believe there is anything inherently wrong with Zend\Acl. The various modules pretty much only provide two features:
 - simplified/unified loading of roles and resources through events or "providers"
 - identity integration (e.g. integration with ZfcUser, being able to query based on the currently authenticated user, etc.)

Neither of these are things you would necessarily want to do with an ACL, so I think it's entirely appropriate to have modules assist with these things. Any particular application might want to handle ACL loading its own way, and some applications might want to query an ACL based on a role outside the currently authenticated set of roles.

The concern has also been raised that loading roles/resources Zend\Acl can be a bottleneck in dynamic applications with large (and growing) numbers of roles and/or resources. I've addressed this concern in more detail in this comment: https://github.com/ZF-Commons/RFC/issues/1#issuecomment-7170924

The only potential problem I can see is telling Zend\Acl\Assertion\AssertionInterface which instance of a resource you want to query (i.e. you want to call isAllowed on blog post #27). Not only are there workarounds to this problem, but fixing it should only require a minor refactoring to AssertionInterface instead of an entire rewrite.

I feel I've worked with Zend\Acl fairly extensively, and I think the component is pretty solid. Anyone voting +1 to remove it needs to provide some strong reasoning as to what's wrong, why it's wrong, and (preferably) how it should be.

---
Ben Youngblood

[hidden email]

On Sun, Jul 22, 2012 at 11:45 PM, D. J. <[hidden email]> wrote:

+1

The Acl component has been already dropped from our project.

On Mon, Jul 23, 2012 at 2:38 PM, Rob Allen <[hidden email]> wrote:

Hi all,


I've seen some discussion about Zend\Acl and whether it's the best it could be for ZF2.0 [1]. To the best of my knowledge, there's at least 3 modules that do their own Acl, presumably because Zend\Acl isn't good enough?

Does anyone have an opinion on whether it's good to go or whether we should pull it from 2.0, do an RFC, re-work it and then introduce for 2.1?


Regards,

Rob...


[1]: https://github.com/ZF-Commons/RFC/issues/1#issuecomment-7164039 - the thread is mostly about which Acl module should integrate with ZfcUser, but the comments on Zend\Acl is relevant.

--

Taiwen Jiang (aka D.J.)

Build Xoops Engine

http://www.xoopsengine.org

web and mobile application platform

CTO for EEFOCUS.com

Leading social platform for electronics professionals

[Jurian Sluiman-3]

2012/7/23 Rob Allen <[hidden email]>

Hi all,


I've seen some discussion about Zend\Acl and whether it's the best it could be for ZF2.0 [1]. To the best of my knowledge, there's at least 3 modules that do their own Acl, presumably because Zend\Acl isn't good enough?

Does anyone have an opinion on whether it's good to go or whether we should pull it from 2.0, do an RFC, re-work it and then introduce for 2.1?


Regards,

Rob...


[1]: https://github.com/ZF-Commons/RFC/issues/1#issuecomment-7164039 - the thread is mostly about which Acl module should integrate with ZfcUser, but the comments on Zend\Acl is relevant.

Obviously I agree with this suggestion, but I'd like to point out a few additional topics:

1. In the October meeting [1] there was already a decision about this: Zend\Acl needs to be refactored to use SPL datastructures internally. This would improve performance and for an 2.1 release the Zend\Rbac component might be developed. However, nobody has had time to do this refactoring, so Zend\Acl is still in the "old" state (except some CS fixes afaik). Not to blame anyone here, but there just wasn't time for it.

2. There is no need for a big overhaul imho. I also agree with Ben Youngblood here [2] where a few optimizations might already result in a "zf2-ready" component. But I much better prefer a little waiting time above a complete 2.x series where everybody use their own Acl mitigating the Zend\Acl problems. Zend\Acl should address a generic framework-style problem where the Acl modules should address the userland problem.

[1] http://framework.zend.com/wiki/display/ZFDEV2/2011-10-26+Meeting+Log#2011-10-26MeetingLog-ACL%2FRBAC

[2] https://github.com/ZF-Commons/RFC/issues/1#issuecomment-7170924

PS. We've already five ACL modules according to the RFC you link to: ZfcAcl, SpiffySecurity, BjyAuthorize, SwAcl, SdsAccessControlModule :)

--
Jurian Sluiman

[Artur Bodera]

On Mon, Jul 23, 2012 at 9:04 AM, Ben Youngblood <[hidden email]> wrote:

-1.

Three modules exist in order to simplify its usage. Here is a rough timeline: ZfcAcl came first, but a lot of people found it difficult to extend. SpiffyJr started writing SpiffySecurity, then decided he wanted to go with an RBAC solution instead of ACL. As a response, I went ahead and wrote BjyAuthorize which is based ideas from both SpiffySecurity and ZfcAcl.

I don't believe there is anything inherently wrong with Zend\Acl. The various modules pretty much only provide two features:
 - simplified/unified loading of roles and resources through events or "providers"
 - identity integration (e.g. integration with ZfcUser, being able to query based on the currently authenticated user, etc.)

Neither of these are things you would necessarily want to do with an ACL, so I think it's entirely appropriate to have modules assist with these things. Any particular application might want to handle ACL loading its own way, and some applications might want to query an ACL based on a role outside the currently authenticated set of roles.

The concern has also been raised that loading roles/resources Zend\Acl can be a bottleneck in dynamic applications with large (and growing) numbers of roles and/or resources. I've addressed this concern in more detail in this comment: https://github.com/ZF-Commons/RFC/issues/1#issuecomment-7170924

The only potential problem I can see is telling Zend\Acl\Assertion\AssertionInterface which instance of a resource you want to query (i.e. you want to call isAllowed on blog post #27). Not only are there workarounds to this problem, but fixing it should only require a minor refactoring to AssertionInterface instead of an entire rewrite.

I feel I've worked with Zend\Acl fairly extensively, and I think the component is pretty solid. Anyone voting +1 to remove it needs to provide some strong reasoning as to what's wrong, why it's wrong, and (preferably) how it should be.

To quote myself from github comment:

@bjyoungblood I know this solution, I've been doing that 5 years ago and it sucks. I ended removing Zend_Acl completely.

Zend\Acl\Assertion is a "last resort" type of thing. If I need a custom function to inject models every time for each query, then why would I need the whole Acl component? Why not just

Service\Permissions::hasAccess(UserModel $user, $what)

.... a custom service that does the same thing, but does not require instantiation and will do basically what theHasPermissionAssertion above does + one more if for the actual check.

Of course this totally ignores user groups, permissions, multiple resources etc. Again - if primitive Zend\Acl container is injected with real-time data each time there's an assertion, then why do I need the Acl? why all this overhead? If it's all JIT injection, then the container would (at any given time) only contain 1 role, 1 resource and a few rules ?

I won't even go into permission queries - for example: show me all users that have write access to resources belonging to group resource_group_a. With current implementation, impossible unless you instantiate each and every model from db, then go with each and every resource, all rules and assertions, and loop through the whole thing. Good luck :)

You've just confirmed what I said earlier, by stating it's a workaround. My proposal is to forget workarounds and build a proper 2012 php acl solution, make it scallable to make both small developers happy, and put MS ActiveDirectory ACL to shame ;) We can also easily make the new component BC with old one, give it the same in-memory containers (adapters), rules, resources and roles.

-- 
      __
     /.)\   [phone]
     \(./   [hidden email]

 

[Artur Bodera]

On Mon, Jul 23, 2012 at 9:06 AM, Jurian Sluiman <[hidden email]> wrote:

2. There is no need for a big overhaul imho. I also agree with Ben Youngblood here [2] where a few optimizations might already result in a "zf2-ready" component. But I much better prefer a little waiting time above a complete 2.x series where everybody use their own Acl mitigating the Zend\Acl problems. Zend\Acl should address a generic framework-style problem where the Acl modules should address the userland problem.

I disagree. ZF2 is our only chance for big BC breaks. 

Zend\Acl is just Zend_Acl in namespaces. It's old and in my personal opinion - useless. Forget me. The thing is, there are people with real ideas we can work on. There is real criticism here and real ideas for enhancements and new features we could implement. 

Remember that ACL is just a single security model - there are many more that'd be suitable for web apps in different shapes and sizes - http://en.wikipedia.org/wiki/Computer_security_model. 

Maybe instead of Zend\Acl we should talk more Zend\Security ? ps: marketing-wise, that ns would look awesome if included in the zf2 core ;) It could also group other security-related components.

Right now, I believe it's easier to reboot and start fresh with an RFC and use the "ZF2 opportunity" to remove old stuff. If we can't make it before 2.0.0 we should remove old component to avoid confusion and re-introduce it in 2.1 or whenever we're ready.

-- 
      __
     /.)\   [phone]
     \(./   [hidden email]

 

[Marco Pivetta]

@Arthur: on the other side, Zend\Acl can still be useful, especially now that it is available as a composer package. It does its job for simpler apps after all.

It could be deprecated or just not be enhanced, and since the idea seems to build a Zend\Rbac|Zend\Security instead (didn't follow closely the discussion on Zfc :( ), I don't see any problems in keeping something that is still very stable and well known without bringing some real innovation to it. As already pointed out, we won't really get anywhere without a rewrite, and having that major rewrite within a Zend\Security namespace seems to be a good idea!

Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    

On 23 July 2012 10:56, Artur Bodera <[hidden email]> wrote:

On Mon, Jul 23, 2012 at 9:06 AM, Jurian Sluiman <[hidden email]> wrote:

2. There is no need for a big overhaul imho. I also agree with Ben Youngblood here [2] where a few optimizations might already result in a "zf2-ready" component. But I much better prefer a little waiting time above a complete 2.x series where everybody use their own Acl mitigating the Zend\Acl problems. Zend\Acl should address a generic framework-style problem where the Acl modules should address the userland problem.

I disagree. ZF2 is our only chance for big BC breaks. 

Zend\Acl is just Zend_Acl in namespaces. It's old and in my personal opinion - useless. Forget me. The thing is, there are people with real ideas we can work on. There is real criticism here and real ideas for enhancements and new features we could implement. 

Remember that ACL is just a single security model - there are many more that'd be suitable for web apps in different shapes and sizes - http://en.wikipedia.org/wiki/Computer_security_model. 

Maybe instead of Zend\Acl we should talk more Zend\Security ? ps: marketing-wise, that ns would look awesome if included in the zf2 core ;) It could also group other security-related components.

Right now, I believe it's easier to reboot and start fresh with an RFC and use the "ZF2 opportunity" to remove old stuff. If we can't make it before 2.0.0 we should remove old component to avoid confusion and re-introduce it in 2.1 or whenever we're ready.

-- 
      __
     /.)\   <a href="tel:%2B48%20695%20600%20936" value="[phone]" target="_blank">[phone]

     \(./   [hidden email]

 

[Tomáš Fejfar]

Zend_Acl (i.e. ZF1) can be used very well until ZF2 Acl/RBAC is ready. I think dropping it is the right solution. 

On Mon, Jul 23, 2012 at 11:17 AM, Marco Pivetta <[hidden email]> wrote:

@Arthur: on the other side, Zend\Acl can still be useful, especially now that it is available as a composer package. It does its job for simpler apps after all.

It could be deprecated or just not be enhanced, and since the idea seems to build a Zend\Rbac|Zend\Security instead (didn't follow closely the discussion on Zfc :( ), I don't see any problems in keeping something that is still very stable and well known without bringing some real innovation to it. As already pointed out, we won't really get anywhere without a rewrite, and having that major rewrite within a Zend\Security namespace seems to be a good idea!

Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    

On 23 July 2012 10:56, Artur Bodera <[hidden email]> wrote:

On Mon, Jul 23, 2012 at 9:06 AM, Jurian Sluiman <[hidden email]> wrote:

2. There is no need for a big overhaul imho. I also agree with Ben Youngblood here [2] where a few optimizations might already result in a "zf2-ready" component. But I much better prefer a little waiting time above a complete 2.x series where everybody use their own Acl mitigating the Zend\Acl problems. Zend\Acl should address a generic framework-style problem where the Acl modules should address the userland problem.

I disagree. ZF2 is our only chance for big BC breaks. 

Zend\Acl is just Zend_Acl in namespaces. It's old and in my personal opinion - useless. Forget me. The thing is, there are people with real ideas we can work on. There is real criticism here and real ideas for enhancements and new features we could implement. 

Remember that ACL is just a single security model - there are many more that'd be suitable for web apps in different shapes and sizes - http://en.wikipedia.org/wiki/Computer_security_model. 

Maybe instead of Zend\Acl we should talk more Zend\Security ? ps: marketing-wise, that ns would look awesome if included in the zf2 core ;) It could also group other security-related components.

Right now, I believe it's easier to reboot and start fresh with an RFC and use the "ZF2 opportunity" to remove old stuff. If we can't make it before 2.0.0 we should remove old component to avoid confusion and re-introduce it in 2.1 or whenever we're ready.

-- 
      __
     /.)\   <a href="tel:%2B48%20695%20600%20936" value="[phone]" target="_blank">[phone]

     \(./   [hidden email]

 

[Artur Bodera]

On Mon, Jul 23, 2012 at 11:17 AM, Marco Pivetta <[hidden email]> wrote:

@Arthur: on the other side, Zend\Acl can still be useful, especially now that it is available as a composer package. It does its job for simpler apps after all.
It could be deprecated or just not be enhanced, and since the idea seems to build a Zend\Rbac|Zend\Security instead (didn't follow closely the discussion on Zfc :( ), I don't see any problems in keeping something that is still very stable and well known without bringing some real innovation to it. As already pointed out, we won't really get anywhere without a rewrite, and having that major rewrite within a Zend\Security namespace seems to be a good idea!

Marco - here is the problem with this solution:

1) We keep that (simple) Zend\Acl in ZF2.

2) It gets into ZF2.0.0

3) People start using it... 

4) Later ... we create Zend\Security\* with ACL, RBAC, LBAC etc.

5) Now you have BOTH ---- Zend\Acl  +  Zend\Security\Acl 

6) You cannot remove Zend\Acl, because people are using it....

-- 
      __
     /.)\   [phone]
     \(./   [hidden email]

 

[Tomáš Fejfar]

+1 Exactly my point. 

On Mon, Jul 23, 2012 at 12:49 PM, Artur Bodera <[hidden email]> wrote:

On Mon, Jul 23, 2012 at 11:17 AM, Marco Pivetta <[hidden email]> wrote:

@Arthur: on the other side, Zend\Acl can still be useful, especially now that it is available as a composer package. It does its job for simpler apps after all.
It could be deprecated or just not be enhanced, and since the idea seems to build a Zend\Rbac|Zend\Security instead (didn't follow closely the discussion on Zfc :( ), I don't see any problems in keeping something that is still very stable and well known without bringing some real innovation to it. As already pointed out, we won't really get anywhere without a rewrite, and having that major rewrite within a Zend\Security namespace seems to be a good idea!

Marco - here is the problem with this solution:

1) We keep that (simple) Zend\Acl in ZF2.

2) It gets into ZF2.0.0

3) People start using it... 

4) Later ... we create Zend\Security\* with ACL, RBAC, LBAC etc.

5) Now you have BOTH ---- Zend\Acl  +  Zend\Security\Acl 

6) You cannot remove Zend\Acl, because people are using it....

-- 
      __
     /.)\   <a href="tel:%2B48%20695%20600%20936" value="[phone]" target="_blank">[phone]
     \(./   [hidden email]

 

[Maks3w]

Zend\Acl has not had any improvement since it was imported from ZF1.

The only differences at this moment are Exceptions milestone, Interface renaming and some methos has been renamed (Ex: has() -> hasResource())

The component doesn't have dependencies with other ZF2 components so the code still as the original except for the changes mentioned above.

This is the list of changes needed at this moment for transitioning dependent components of Zend\Acl

https://github.com/Maks3w/zf2/compare/refactor-components-back-to-zend_acl-v1

I think that is perfectly suitable remove Zend\Acl 2beta in favor of Zend\Acl 1

---

De: Rob Allen <[hidden email]>
Para: "[hidden email] Contributors" <[hidden email]>
Enviado: Lunes 23 de julio de 2012 8:38
Asunto: [zf-contributors] Remove Zend\Acl from 2.0, update and then add to 2.1?

Hi all,


I've seen some discussion about Zend\Acl and whether it's the best it could be for ZF2.0 [1]. To the best of my knowledge, there's at least 3 modules that do their own Acl, presumably because Zend\Acl isn't good enough?

Does anyone have an opinion on whether it's good to go or whether we should pull it from 2.0, do an RFC, re-work it and then introduce for 2.1?


Regards,

Rob...


[1]: https://github.com/ZF-Commons/RFC/issues/1#issuecomment-7164039 - the thread is mostly about which Acl module should integrate with ZfcUser, but the comments on Zend\Acl is relevant.

[weierophinney]

Top-posting, as I want to reply once, instead of to many separate
replies.

First, yes, Zend\Acl is basically the same as in ZF1. That's neither an
argument for or against inclusion in ZF2.

Second, yes, Zend\Acl needs some internal refactoring to use SPL
interfaces. This will mainly improve its performance -- but does not
necessarily affect the external API. This sort of thing can happen
post-2.0.0-stable.

Third, a lot of the arguments against including it are largely due to
misunderstanding the purpose of Zend\Acl, and/or wanting it to do
something different than what it does. Zend\Acl is an access control
list, and follows a very specific algorithm: roles request rights to
resources. From what I've seen, a large number of people want a
role-based access control (RBAC) implementation. We can offer an RBAC in
parallel to ACL; they are not mutually exclusive.

Fourth, Artur brings up the most pointed reasons for refactoring:
querying various aspects of the ACL, such as who has a specific
permission to a resource, etc. That said, I'd also argue that what he
wants does not necessarily invalidate the current offering. One of the
features of the current implementation is the ability to have dynamic
ACLs, so that you do not necessarily need to build the entire ACL tree
on any given request, just the bits relevant to the request. As such, a
feature such as the one Artur desires simply does not fit -- that falls
into the scope of a different implementation. I believe such an
implementation can live in parallel.

I think at this point the only real question I have is what _namespace_
our current implementation should live in for the stable release. Right
now, it's a top-level component, and I wonder if it should live in a
"Zend\Security" namespace, or a "Zend\Permissions" namespace.


-- Rob Allen <[hidden email]> wrote
(on Monday, 23 July 2012, 07:38 AM +0100):

> Hi all,
>
>
> I've seen some discussion about Zend\Acl and whether it's the best it could be for ZF2.0 [1]. To the best of my knowledge, there's at least 3 modules that do their own Acl, presumably because Zend\Acl isn't good enough?
>
> Does anyone have an opinion on whether it's good to go or whether we should pull it from 2.0, do an RFC, re-work it and then introduce for 2.1?
>
>
> Regards,
>
> Rob...
>
>
> [1]: https://github.com/ZF-Commons/RFC/issues/1#issuecomment-7164039 - the thread is mostly about which Acl module should integrate with ZfcUser, but the comments on Zend\Acl is relevant.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

[Artur Bodera]

On Mon, Jul 23, 2012 at 4:24 PM, Matthew Weier O'Phinney <[hidden email]> wrote:

I think at this point the only real question I have is what _namespace_
our current implementation should live in for the stable release. Right
now, it's a top-level component, and I wonder if it should live in a
"Zend\Security" namespace, or a "Zend\Permissions" namespace.

It's not about RBAC or lack thereof.

Please read my note (above) on including Zend\Acl in current version and people using in their projects, and then us removing it completely or refactoring to the point that it will not be BC. If we include the old thing in 2.0.0 we risk confusion with the new, fully-fledged, multiple security models, security component - after it's introduced. If we put it into Zend\Security it's even worse, because we use that brand new, shiny namespace and stuff it with ye olde component we clearly plan to refactor (with very high BC break probability).

-- 
      __
     /.)\   [phone]
     \(./   [hidden email]

[weierophinney]

-- Artur Bodera <[hidden email]> wrote
(on Monday, 23 July 2012, 05:08 PM +0200):

> On Mon, Jul 23, 2012 at 4:24 PM, Matthew Weier O'Phinney <[hidden email]>
> wrote:
>
>
>     I think at this point the only real question I have is what
>     _namespace_ our current implementation should live in for the
>     stable release. Right now, it's a top-level component, and I
>     wonder if it should live in a "Zend\Security" namespace, or a
>     "Zend\Permissions" namespace.
>
>
> It's not about RBAC or lack thereof.

I didn't state that. I stated that as _one_ common thread.

> Please read my note (above) on including Zend\Acl in current version
> and people using in their projects, and then us removing it completely
> or refactoring to the point that it will not be BC.

As I stated in my reply, the only concrete refactoring identified deals
with internal implementation, not the external API. The component as it
stands, and with its current API, is still useful to many, many
developers. I doubt we will need to break BC, or remove it.

My argument is that we may have _additional_ permissions-related
components we want to add, including an RBAC implementation, and
potentially another ACL-style implementation with a different
(potentially overlapping) feature-set.

> If we include the old thing in 2.0.0 we risk confusion with the new,
> fully-fledged, multiple security models, security component - after
> it's introduced.  

As noted, they suit different paradigms. RBAC is different from ACL.
Dynamic ACL is different than a static, queryable tree. CACL and DACL
differ from our ACL implementation.

My point is that different security models and different application
architectures may require different approaches. These approaches can
live in parallel.

> If we put it into Zend\Security it's even worse, because we use that
> brand new, shiny namespace and stuff it with ye olde component we
> clearly plan to refactor (with very high BC break probability).

See above. If you feel that strongly, we'll leave it where it is, but I
think that will cause more confusion later, when people wonder why it's
a top-level component and not under the Zend\Security namespace where
the other permission APIs live.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

[DeNix]

23.07.2012 18:24, Matthew Weier O'Phinney пишет:
> I think at this point the only real question I have is what _namespace_
> our current implementation should live in for the stable release. Right
> now, it's a top-level component, and I wonder if it should live in a
> "Zend\Security" namespace, or a "Zend\Permissions" namespace.
+1 for moving it to Zend\Security
and I agree that different ACL or RBAC implementations could co-exist in
Security namespace

one note though
current Acl uses camelCase config keys for rules, this is against CS
so I guess bit of refactoring is needed anyway

Denis

[xoops]

Objection to moving to Security.

Don't get Security mixed up.

On Tue, Jul 24, 2012 at 1:01 AM, Denis Portnov <[hidden email]> wrote:

23.07.2012 18:24, Matthew Weier O'Phinney пишет:

I think at this point the only real question I have is what _namespace_
our current implementation should live in for the stable release. Right
now, it's a top-level component, and I wonder if it should live in a
"Zend\Security" namespace, or a "Zend\Permissions" namespace.

+1 for moving it to Zend\Security
and I agree that different ACL or RBAC implementations could co-exist in Security namespace

one note though
current Acl uses camelCase config keys for rules, this is against CS
so I guess bit of refactoring is needed anyway

Denis

--

Taiwen Jiang (aka D.J.)

Build Xoops Engine

http://www.xoopsengine.org

web and mobile application platform

CTO for EEFOCUS.com

Leading social platform for electronics professionals

[Roediger, Tim]

Quick note about what the superdweebie/accessControlModule I wrote is for (mentioned below) …

 

I have the superdweebie/doctrineExtensions collection – one extension provides role based access to doctrine mongo odm documents. In particular, read access control is done with a doctrine filter – so documents don’t need to be loaded, then tested for read access. My whole access control architecture has been moulded to allow this nice little efficiency. If someone happens to be using doctrineExtensions to give access control on individual documents, and also wants to control access to mvc controllers, then my accessControlModule allows that using the same role definitions. (accessControlModule could be used on its own, but if that was the case, I’d seriously consider Zend\Acl instead).

 

So, accessControlModule doing stuff that Zend\Acl isn’t trying to do, or really should try to do, which is why it exists as a separate module in the first place – it is not an indication of weakness with Zend\Acl.

 

Tim Roediger

 

From: Jurian Sluiman [mailto:[hidden email]]
Sent: Monday, 23 July 2012 5:06 PM
To: [hidden email] Contributors
Cc: Rob Allen
Subject: Re: [zf-contributors] Remove Zend\Acl from 2.0, update and then add to 2.1?

 

2012/7/23 Rob Allen <[hidden email]>

Hi all,


I've seen some discussion about Zend\Acl and whether it's the best it could be for ZF2.0 [1]. To the best of my knowledge, there's at least 3 modules that do their own Acl, presumably because Zend\Acl isn't good enough?

Does anyone have an opinion on whether it's good to go or whether we should pull it from 2.0, do an RFC, re-work it and then introduce for 2.1?


Regards,

Rob...


[1]: https://github.com/ZF-Commons/RFC/issues/1#issuecomment-7164039 - the thread is mostly about which Acl module should integrate with ZfcUser, but the comments on Zend\Acl is relevant.

Obviously I agree with this suggestion, but I'd like to point out a few additional topics:

 

1. In the October meeting [1] there was already a decision about this: Zend\Acl needs to be refactored to use SPL datastructures internally. This would improve performance and for an 2.1 release the Zend\Rbac component might be developed. However, nobody has had time to do this refactoring, so Zend\Acl is still in the "old" state (except some CS fixes afaik). Not to blame anyone here, but there just wasn't time for it.

 

2. There is no need for a big overhaul imho. I also agree with Ben Youngblood here [2] where a few optimizations might already result in a "zf2-ready" component. But I much better prefer a little waiting time above a complete 2.x series where everybody use their own Acl mitigating the Zend\Acl problems. Zend\Acl should address a generic framework-style problem where the Acl modules should address the userland problem.

 

[1] <a href="http://framework.zend.com/wiki/display/ZFDEV2/2011-10-26&#43;Meeting&#43;Log#2011-10-26MeetingLog-ACL%2FRBAC">http://framework.zend.com/wiki/display/ZFDEV2/2011-10-26+Meeting+Log#2011-10-26MeetingLog-ACL%2FRBAC

[2] https://github.com/ZF-Commons/RFC/issues/1#issuecomment-7170924

 

PS. We've already five ACL modules according to the RFC you link to: ZfcAcl, SpiffySecurity, BjyAuthorize, SwAcl, SdsAccessControlModule :)

--
Jurian Sluiman

[akrabat]

Hi all,


On 23 Jul 2012, at 15:24, Matthew Weier O'Phinney wrote:

> I think at this point the only real question I have is what _namespace_
> our current implementation should live in for the stable release. Right
> now, it's a top-level component, and I wonder if it should live in a
> "Zend\Security" namespace, or a "Zend\Permissions" namespace.

Not Zend\Security.

If there's going to be more than one ACL implementation within ZF, then we have two choices:

1. Separate top level components: Zend\Acl, Zend\Rbac, Zend\Dacl, etc
2. A parent namespace: Zend\Permissions or Zend\AccessControl would be obvious choices.

Personally, I don't mind with either way.  


In any case, it would be nice if someone ensured that the public API to Zend\Acl was correct for ZF2 before we hit stable.



Regards,

Rob...

[Artur Bodera]

On Mon, Jul 23, 2012 at 5:59 PM, Matthew Weier O'Phinney <[hidden email]> wrote:

> If we put it into Zend\Security it's even worse, because we use that
> brand new, shiny namespace and stuff it with ye olde component we
> clearly plan to refactor (with very high BC break probability).

See above. If you feel that strongly, we'll leave it where it is, but I
think that will cause more confusion later, when people wonder why it's
a top-level component and not under the Zend\Security namespace where
the other permission APIs live.

That is the problem... none of these places is perfect.

Zend\Security\Acl

 - bad because it breaks BC

 - bad because we pollute completely new (fresh) namespace with old

 - bad because acl does not == security (it's just a small part of a bigger concept)

Zend\Acl

 - bad if we wanted to remove/deprecated it one day.

 - bad if we'll also have Zend\Security\Acl (different implementations in the same framework)

Actually, Zend\Acl has 1 less downside, so it's probably better to keep it. It will live its live for as long as people use it, but in the meantime - we'll introduce completely new namespace for a completely new (modular, more robust) implementation - Zend\Security or otherwise. That might come around 2.1...

-- 
      __
     /.)\   [phone]
     \(./   [hidden email]

[Maks3w]

I think that the backward compatibility shouldn't be part of the equation.

Zend\Date, Zend\Locale required more changes in the code but Zend\Acl only require a minimal amount of changes to switch back to ZF1 Zend_Acl.

---

De: Artur Bodera <[hidden email]>
Para: [hidden email]
Enviado: Martes 24 de julio de 2012 19:29
Asunto: Re: [zf-contributors] Remove Zend\Acl from 2.0, update and then add to 2.1?

On Mon, Jul 23, 2012 at 5:59 PM, Matthew Weier O'Phinney <[hidden email]> wrote:

> If we put it into Zend\Security it's even worse, because we use that
> brand new, shiny namespace and stuff it with ye olde component we
> clearly plan to refactor (with very high BC break probability).

See above. If you feel that strongly, we'll leave it where it is, but I
think that will cause more confusion later, when people wonder why it's
a top-level component and not under the Zend\Security namespace where
the other permission APIs live.

That is the problem... none of these places is perfect.

Zend\Security\Acl

 - bad because it breaks BC

 - bad because we pollute completely new (fresh) namespace with old

 - bad because acl does not == security (it's just a small part of a bigger concept)

Zend\Acl

 - bad if we wanted to remove/deprecated it one day.

 - bad if we'll also have Zend\Security\Acl (different implementations in the same framework)

Actually, Zend\Acl has 1 less downside, so it's probably better to keep it. It will live its live for as long as people use it, but in the meantime - we'll introduce completely new namespace for a completely new (modular, more robust) implementation - Zend\Security or otherwise. That might come around 2.1...

-- 
      __
     /.)\   [phone]
     \(./   [hidden email]