Future

[basz]

Dear @acrnogor, @adamh114, @Alexandre-T, @amohammad, @andrconstruction, @andrey-mokhov, @arekkas, @bacinsky, @baiyinnamula, @bakura10, @gregorybesson, @basz, @belgattitude, @bingchengcool, @bladeofsteel, @BrunoSpy, @buonaparte, @carnage, @chenxinwen, @chpxwdd, @chukShirley, @cletsimon, @CodericSandbox, @codewebagency, @CrispCrumbs, @Danielss89, @danizord, @dariodjuric, @DavidHavl, @davidwindell, @devsnippet, @divix1988, @djokodonev, @dkmuir, @dragoste, @dudko-av, @elijah513, @ellipizle, @esserj, @evolic, @fabiocarneiro, @FishingCat, @francisdaigle, @GeeH, @generalredneck, @gitter-badger, @grizzm0, @guillaume-pagnard, @gzliumiao, @hamilok, @hidahua, @Iraecio, @itmyprofession, @jhue, @jmleroux, @joacub, @JPG-Consulting, @KadnikovVN, @kelsey9649, @KKonstantinov, @krisstwo, @lahirwisada, @Lansoweb, @lasimon, @lfq618, @lokrain, @machek, @Maks3w, @MalteGerth, @manuakasam, @marcosli, @meijssen, @MidnightDesign, @munishchopra, @Muzaffardjan, @neoglez, @Nirzol, @Nitecon, @nkuznetsova, @nomaanp, @nuxwin, @Ocramius, @ojhaujjwal, @Orkin, @PowerKiKi, @ppeiris, @prolic, @nasko, @protecinnovations, @richardjennings, @rizaozden, @romanov-acc, @rufinus, @samsonasik, @sasezaki, @screws0ft, @Sequencesh, @sica07, @siddik12, @slacker775, @SpiffyJrTravis, @stefankleff, @steverhoades, @surjit, @svycka, @tad3j, @telkins, @thestanislav, @tklever, @trinhdung0911, @trixster, @unixmen, @vahid-sohrabloo, @vraskin, @webdevilopers, @webimpress, @wiggy, @wilonth, @Wilt, @Xerkus, @ZeinEddin, @zer0c14, @zhoujievet, @zionsg, @zxf104

Version 3.0 of this library has been 'in the works' for a long time. Myself and others have done a quite a bit of work on it about a year ago and now things are becoming more active again. Also I have joined with @prolic as maintainers as some of the original maintainers have moved on.

The goal for 3.0 was never to be fully backward compatible, but to create a library that was a bit more modern and less integrated with the zend framework. I don't believe many people are using the development branch in production, but it is functional.

The 2 version does have quite a lot of downloads (according to packagist) so I think we should ask all you to express you opinions. And now that I have restarted work on it I would like to ask you about features or specs you would insist on.

• Removed support for zf2 components. It gives cleaner code and I don't care so much about compatibility. Do you?
• Additionally support for php56 was dropped. Again I wouldn't be against dropping support for php70 too. Would you?
• Are you waiting on a v3?
• Would you use it in your existing projects?

note. we will continue to support the v2 till EOL of php56 (active support already is)

Kind regards

Bas(z) Kamer

ps chat available on https://gitter.im/ZFCommons/zfc-rbac

[andrey-mokhov]

• Removed support for zf2 components. - no problem
• Additionally support for php56 was dropped. - ok
• Are you waiting on a v3? - I didn't follow for changes
• Would you use it in your existing projects? - may be

[andrconstruction]

Removed support for zf2 components. - problem
Additionally support for php56 was dropped. - ok
Are you waiting on a v3? - Yep
Would you use it in your existing projects? - may be

[lowtower]

Removed support for zf2 components. - no problem

Additionally support for php56 was dropped. - no problem

Are you waiting on a v3? - Yes, I do

Would you use it in your existing projects? - Yes, I would

Focus on middleware and compatibility with zend-expressive would be fine

[svycka]

Removed support for zf2 components.

ok, but only if we have good reason

Additionally support for php56 was dropped.

ok, I would even preffer drop 7.0 because many that support 7.0 already upgraded or will upgrade soon to 7.1(has many good feaures like optional typehints this really hurts in 7.0)

Are you waiting on a v3?

not really, but I heard this will be focused on middleware? Most my projects still use zend-mvc so I would still expect support for zend-mvc. Also I am always interested in this kind of updates.

Would you use it in your existing projects?

of course, but only if will be possible to update(no big BC breaks that I would have to invest more than few days to update), also I still use modules that does not support zf3 packages so if we drop zf2 I may can't use yet.

[prolic]

I don't know if all people got notifications, so I mention them again, sorry if you get the email twice:

/cc @hidahua, @Iraecio, @itmyprofession, @Jhue, @jmleroux, @joacub, @JPG-Consulting, @KadnikovVN, @kelsey9649, @KKonstantinov, @krisstwo, @lahirwisada, @Lansoweb, @lasimon, @lfq618, @lokrain, @machek, @Maks3w, @MalteGerth, @manuakasam, @marcosli, @meijssen, @MidnightDesign, @munishchopra, @Muzaffardjan, @neoglez, @Nirzol, @Nitecon, @nkuznetsova, @nomaanp, @nuxwin, @Ocramius, @ojhaujjwal, @Orkin, @PowerKiKi, @ppeiris

[prolic]

I don't know if all people got notifications, so I mention them again, sorry if you get the email twice:

/cc @nasko, @protecinnovations, @richardjennings, @rizaozden, @romanov-acc, @rufinus, @samsonasik, @sasezaki, @screws0ft, @Sequencesh, @sica07, @siddik12, @slacker775, @SpiffyJrTravis, @stefankleff, @steverhoades, @surjit, @svycka, @tad3j, @telkins, @thestanislav, @tklever, @trinhdung0911, @trixster, @unixmen, @vahid-sohrabloo, @vraskin, @webdevilopers, @webimpress, @wiggy, @wilonth, @Wilt, @Xerkus, @ZeinEddin, @zer0c14, @zhoujievet, @zionsg, @zxf104

[prolic]

To ease the voting process, I ask the questions separately here, please leave thumbs up or down. This way we can use the comments for more discussions, without repeating the same stuff again and again.

[prolic]

Should we remove support for zf2 and allow zf3 only?

[prolic]

Should we drop support for PHP 5.6 and require PHP 7.0?

[prolic]

Should we drop support for PHP 7.0 and require PHP 7.1?

[prolic]

Are you waiting on a v3 of ZfcRbac?

[prolic]

Would you use it in your existing projects?

[prolic]

Should we provide features to allow ZfcRbac to be used as middleware for easy integration in zend-expressive f.e.?

[svycka]

@prolic can you change questions?

Should we drop support for PHP 5.6 and require PHP 7.0?
Should we drop support for PHP 7.0 and require PHP 7.1?

its not clear for what we voting if I prefer 7.1 shoud I vore for second and down vote first? maybe remove and require PHP 7.x?

[prolic]

You can upvote both if you want, which means you flag support for 7.1, but if that is not accepted, at least drop 5.6 Am 07.04.2017 14:28 schrieb "Vytautas Stankus" <[email protected]>:

…

@prolic <https://github.com/prolic> can you change questions? Should we drop support for PHP 5.6 and require PHP 7.0? Should we drop support for PHP 7.0 and require PHP 7.1? its not clear for what we voting if I prefer 7.1 shoud I vore for second and down vote first? maybe remove *and require PHP 7.x*? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#367 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAYEvJfbR3fjS77Zsb_V4kEGa0nWhobcks5rtdeAgaJpZM4M18e1> .

[svycka]

@prolic at the moment 6 is for 7.1 and 4 for 7.0 does it mean that 2 is agains 7.0? :) just saying that it is not very clear, but I guess this is not really important as we don't get any downvotes

[Wilt]

"Would you use it in your existing projects?"
That really depends on whether I can somehow make a role/assertion configuration as mentioned before in my issue that can be found here: #270

It doesn't need to work exactly like that, but I should somehow be able to set such a config:

I have several roles for a user that depend on the context. In one context he can have admin rights while in another he has reader rights.

1. collect role for authenticated identity (by passing context to a role provider)
2. find role/assertions configuration for the current resource and this role and current action
3. execute the assertions (passing both the identity and the resource, some of the assertions depend on the identity some on the resource and some on both)
4. get a true or false for all assertions
5. action is only allowed when all assertions return true

An example:

    'role_resolver_map' => [
        Resource::class => SomeRoleResolver::class,
    ],

    //...

    Resource::class => [
        'Administrator' => [
            // Admins are always allowed to create
            'create' => [],
            // Admins are always allowed to read
            'read' => []
        ],
        'Author' => [
            // Authors are allowed to create new resource during daily hours
            'create' => [
               'AssertIsDaytime::class // simple assertion checking time now
            ],
        ],
        'Reader' => [
            // Reader can only read public resource
            'read' => [
                ResourceIsPublic::class // internally checks $resource->isPublic();
            ]
        ],
        'Owner' => [
            // Owner can always read his own resource
            'read' => [],
        ]
    ],

Roles can be hierarchical so an Admin inherits from Author and Author from Reader, meaning an Author is allowed to read if the ResourceIsPublic assertion returns true.
Owner is a separate role and is added to the roles collection for the current identity when this line in the SomeRoleResolver returns true:

$resource->getOwner() === $identity;

We have something custom built heavily inspired on zfc-rbac right now which works according to the above. I hope this is clear, please comment if I need to elaborate.

Looking forward to the next release, I am very willing to contribute where I can!

[wiggy]

• Removed support for zf2 components. - No problem
• Additionally support for php56 was dropped. - I'm OK
• Are you waiting on a v3? - Yes
• Would you use it in your existing projects? - May be

[BrunoSpy]

• Removed support for zf2 components. - No problem
• Additionally support for php56 was dropped. - Well, I don't know...
• Are you waiting on a v3? - No
• Would you use it in your existing projects? - No. My project is used on many servers that are still on php56. And the actual version is working like a charm for me :)

[manuakasam]

The way I see things, the current version is working pretty stable on ZF2 projects. There's not that much need to add more features (at least as far as I can tell), so the ZF2 front is pretty good with the way things are.

As far as a potential new version is concerned, dropping PHP56 is a must. There's just no reason to support old stuff for a new major version. Again, projects running PHP56 will use the current version of Rbac. They don't have the need to update to a new version of Rbac. Therefore we can safely drop support for future versions. Though I'd go with 7.0 as this is the version within Ubuntu 16.04. Jumping to 7.1 would reduce the potential userbase quite a lot.

[bacinsky]

Removed support for zf2 components. - ok
Additionally support for php56 was dropped. - ok
Are you waiting on a v3? - no
Would you use it in your existing projects? - no

I better like libraries, so removing any framework specific support is no problem for me, but I'm too busy to make my projects LTS. Keeping up to date versions with lots of BC breaks for a low level and basically simple functionality is a pain in my ass. I'm still using the 0.2 version... I have to make new high-level application features for my customers not updating thing they cant see, too often, because it breaks the system stability.

[basz]

counts (yes, no/not sure)

Should we remove support for zf2 and allow zf3 only?                   21  7
Should we drop support for PHP 5.6 and require PHP 7.0?                20  8
Should we drop support for PHP 7.0 and require PHP 7.1?                16 12
Are you waiting on a v3 of ZfcRbac?                                    18  6
Would you use it in your existing projects                             20  1 
Should we provide features to allow ZfcRbac to be used as middleware 
for easy integration in zend-expressive f.e.?                          19  -

other notes:

• request for dynamic role/assertion configuration
• manuakasam, nails it pretty good.
• zendframework plans around php version support

[basz]

@/all FYI I've just implemented #379 which is #320 for the develop branch. Comments welcome...