Forward Thinking: Suggested tools for PHP-RBAC

[jburns131]

Intro

This Issue will be used to suggest and discuss tools that might help benefit PHP-RBAC, as either a development tool or and end user tool.

Current Tools Used

PHP-RBAC currently uses git/Github and PHPUnit/DBUnit internally for core library development and testing.

PHP-RBAC has also adopted Composer as a 3rd Party installation and dependency manager.

Your Suggestions

Please leave a suggestion or comment regarding any tool that you think will help PHP-RBAC grow stronger.

While making a suggestion, please include, when possible:

• Tool Name: n/a
• Website: n/a
• A link to it's documentation (if possible): n/a
• Links to the tool in use (examples of other projects using it, use case examples, etc..): n/a

Thanks!

[Bilge]

It would help if you knew what encapsulation is. And PSR.

[Bilge]

Oh yeah, and you should decouple yourself from any database. A permissions library has no business making assumptions about any kind of storage back-end.

[jburns131]

@Bilge,

1. The purpose of this Issue is to suggest 3rd party tools, explain why you think it would help the project, and maybe a link or two to articles about the tool and examples of projects using the tool, i.e. Continuous Integration Tools, Automation Tools, QA Tools
2. We really do appreciate constructive criticism. If anyone would like to suggest a change or improvement to the project please not only mention a topic, but include links to the topic and documentation, use cases, links to projects using what is suggested.

To reply to your comments:

"It would help if you knew what encapsulation is. And PSR."

If you take a closer look you will see that the core library does encapsulate the functionality of manipulating permissions, roles, associations between the two, and associations between users and roles. If you'll take an even closer look, you'll notice that v2.0 introduced an outer wrapper to comply with PSR-0, PSR-1 ad PSR-2 ;-)

"... and you should decouple yourself from any database."

This is not a typical "Permission Library", where you use the library to implement your own permission system. This library complies with the NIST Level 2 Hierarchical Role Based Access Control standard. The database schema, along with the queries used, both enforce NIST Level 2 conformance and is the reason that PHP-RBAC performs so well as the size of the Role/Permission hierarchies scale.

Personally I have contemplated proposing that we move to a data abstraction layer, maybe Doctrine or Propel, but the performance hit and loss of flexibility and finely tuned control of the data access layer might be too large when compared to the minor benefits offered by a DAL.

I believe the current setup of creating finely tuned adapters/queries for each DBMS is the best way to go at the moment. And I really doubt a large portion of PHP-RBAC users are going to be using other persistent storage solutions (flat file, csv, xml, json Rbac CRUD??? What?!?! lol).

If I am wrong then please speak up so we can discuss alternatives, but please open a separate Issue for this discussion.

Thanks!

[Bilge]

I'm well aware you were originally asking for third party libraries but they won't help you fix the plethora of problems with this library. You band about the term NIST like it justifies everything you do. I couldn't care less if you're NIST-compliant but even if that could actually be considered a redeeming feature of this library it would be the only one.

If you think PSR-1/2 can be satisfied with a wrapper then you've completely misunderstood the purpose. A discussion around how you failed to embrace PSR-0 is redundant since it is superseded by PSR-4 but clearly you're not doing any form of autoloading when you feel the need to hide requires at the end of files.

You certainly don't understand encapsulation because you expose public properties on your major API access point. Undefined properties I might add. I'm still just scratching the surface, though. On those same lines you will observe they're assigned from a static singleton which is as bizarre as it is ridiculous: a static singleton implies you can only have one instance of users, permissions and roles and yet Rbac only has an instance constructor.

I don't really have the energy to go over any more of this but for anyone else reading I can recommend a good rbac library. Maybe you can learn something from them.

[jburns131]

@Bilge, thank you again for your input.

Please see Project Status and Updates - 01-24-15 to understand where the project was, how it got to this state, and what we plan for the future. This might clear some of the confusion.

You might notice that v2.0 was released prior to PSR-4 being voted in, and PSR-4 is an alternative to PSR-0, not a replacement. That's not to say that we won't be adopting PSR-4 for v3.x, we have not had that discussion yet.

Please open another Issue, or multiple Issues if you would like to address multiple issues with the library.

Please try to keep any criticism positive, and please try to suggest solutions along with any issues you would like to address.

Like I said, any feedback is welcome feedback, and we do take helpful suggestions seriously.

Thanks again!

[jburns131]

Also, once we've finished knocking out v2.0.1 then the discussions regarding the refactoring/cleaning/fixing the entire code base for v3.x will start full swing.

I know we would welcome any contributions you have to offer regarding the future of PHP-RBAC :-)

[Bilge]

PSR-4 is an alternative to PSR-0, not a replacement.

That's patently untrue.

I'd find it a lot easier to be positive if you refrained from consistently showering me with ignorance.

[jburns131]

@Bilge,

1. PSR-4 was proposed as an addition, alternative, and/or alteration, to PSR-0. Please read the 'Overview' section off PSR-4 (www.php-fig.org/psr/psr-4/):

   "This PSR describes a specification for autoloading classes from file paths. It is fully interoperable, and can be used in addition to any other autoloading specification, including PSR-0."

2. There is no need for nasty remarks. I have been respectful and sincere in my responses to you, I expect the same from you. If you would like to be a troll there are plenty of other projects out there.

Thank you.

[Bilge]

Exactly what part of deprecated do you not understand?

[jburns131]

@Bilge,

If you would like to open separate Issues to address valid concerns please do so. After 24 hours from now I will be removing any comments not related to this Issue.

I am done participating in this conversation.

Thank you.

[abiusx]

@Bilge I am the original author of the library. Jesse is nice enough to help make a lot of my geeky stuff consumable by the rest of the world.

Please let me know if you have any questions, or if you'd like to help contribute to the project!

[Kern046]

I've read this conversation, and I believe that my last PR resolves most of the exposed problems.

Please take a look : #65

I wait since a long time to see it merged X) !

[Bilge]

After 24 hours from now I will be removing any comments not related to this Issue.

Why? To bury your embarrassment? I think you should keep everything exactly as it is and learn from it.

If you honestly think someone is going to suggest loads of whizz-bang third party libraries for you to peruse then I apologize for hijacking this ticket, but instead of purging it, remake it and enjoy waiting indefinitely.