On the Zend Blog there's a new tutorial posted that covers the situation where a user has multiple roles and you're using ACLs (access control lists). The post shows how to accomplish this with the ZendAcl component of the Zend Framework.

After covering the essentials of the ZendPermissionsAcl component (Access Control unit, Cross Cutting Concerns module, in the Zend Framework Advanced course), many students have approached me to ask, “what happens if a user has multiple roles?”

In this article I discuss the “traditional” way of handling a user who has multiple roles, and then lay out an easy approach which I simply call Mr. X.

The tutorial starts with a bit of a refresher on the use of the ZendAcl component to define the list of roles and resources (and relating the two). It also covers the "everyone" (anonymous) role and adding that into the mix. The "one user, multiple roles" issue is then solved with a multiCheck function that can verify multiple roles at once. Finally it talks about "Mr. X" and how to add that to all users, assuming that they will have the groups/roles information we need.

On the Pinco.de blog there's a post that covers the use of pivot models for role management in SaaS applications. The tutorial shows how to use the Laravel Eloquent "withPivot" method and a pivot database table to create an easy to use relationship between "users" and "teams" in a PHP application.

If you have ever developed any kind of SaaS app (like Spark), you know what team level role management means. Instead of picking a bad strategy for handling roles, we can bring simple solution by using Pivot Models.

The tutorial starts by talking about "robust permission handling" and why, more often than not, a simpler role-based approach is enough. It then covers the pivot table itself, showing the code to create the table. Next comes the creation of the relationship between teams and users via the withPivot method. With the relationship in place, the article then covers attaching users to a team, generating the models and how to add permission evaluation into the model's functionality.

The Laravel News site has posted an in-depth look at two packages Laravel users can implement to add in role/permission management: Bouncer and Laravel-permission.

Roles and permissions are an important part of many web applications. Laravel historically had a lot of packages for them, and improved the core code as well. So what is the situation on this market today? What packages are the best to use? I’ve picked two.

The post starts off by sharing a few reasons why you might even need these packages with the functionality that Laravel already includes. Most of the reasoning comes from the fact that the framework allows for checks but doesn't provide role/permission management. It then gets into what each of the package provide, how to install them and some example code to put them to use. It also looks at the database structure behind them and how they use that to store the authorization data.

On the Scotch.io site a new tutorial has been posted showing you how to use the Laravel-permission package (from Spatie) to more easily handle permission setup and validation in a Laravel application.

When building an application, we often need to set up an access control list (ACL). An ACL specifies the level of permission granted to a user of an application. For example a user John may have the permission to read and write to a resource while another user Smith may have the permission only to read the resource.

In this tutorial, I will teach you how to add access control to a Laravel app using Laravel-permission package. For this tutorial we will build a simple blog application where users can be assigned different levels of permission.

The tutorial then walks though the installation of the package and some of the new tables it adds to the database when you run the included migrations. It then talks about some of the methods that can be used, both on the backend and in Blade templates, to evaluate if the current user has the roles required. Next up is the creation of the controllers to handle the basic CRUD tasks and working with the blog posts and views to set up the permissions and roles. Finally the tutorial shows the code required to evaluate the roles and permissions of the user and an example of middleware that performs a pre-check to see if a user even has access to manage various pieces of the application.

Continuing on from their previous tutorial looking at auth in Expressive middleware, the Zend Framework blog (and author Matthew Weier O'Phinney) shows an example of using the "zend-permissions-rbac" package from the Zend Framework to handle role-based access control in your application.

In our previous post, we covered authentication of a user via Expressive middleware. In that post, we indicated that we would later discuss authorization, which is the activity of checking if an authenticated user has permissions to perform a specific action, from within the context of a middleware application.

Before we do that, however, we thought we'd introduce zend-permissions-rbac, our lightweight role-based access control (RBAC) implementation.

The article starts off with the Composer command to get the package installed and some basic vocabulary around the role-based access control system. It then gets into some of the basics around creating a role and checking to see if a user (by identifier) has access to a permission. The post also includes an example of how to handle undefined roles more gracefully than the default exception. It goes on to cover role inheritance and the creation of a first "real world" example using the package for complex evaluation. This also includes assigning users roles using an Identity class and how to write custom assertions.

On the Stovepipe Systems blog author Iltar van der Berg has retuned with a continuation of his series on Symfony security basics with this new post covering voters and roles.

In my previous blog post I've explained the basics of authentication, authorization and how this is dealt with in Symfony. Due to the size of the post, I've left out several important topics such as roles and voters; Both an equally important part of authentication and authorization. A common misconception is that roles should be used to check permissions. In fact, they should definitely not be used to check permissions!

He goes on to explain where "roles" come into the process of authentication (not authorization) and how they describe something about the user of the system. With that defined he moves on to the "voters": functionality that "vote" on attributes related to the user/request/resource/etc. and return a pass or fail decision based on their logic. He explains why voters are probably more what most developers are looking for and some reasons to use them over roles. He then ends the post showing how to create your own custom voter and configure it into your application.

Joshua Thijssen has a new post today with a "neat trick" that the Symfony Security component allows - switching (impersonating) another user programatically.

This allows you to login as another user, without supplying their password. Suppose a client of your application has a problem at a certain page which you want to investigate. Sometimes this is not possible under your own account, as you don’t have the same data as the user, so the issue might not even occur in your account. Instead of asking the password from the user itself, which is cumbersome, and not a very safe thing to begin with, you can use the switch-user feature.

He talks about how to enable it, how to use it to switch to another user and, most important, how to restrict its use. He points out that there's no way to define who a user can switch to built-in, so he's come up with a custom "switch listener" to help add in this protection. His "SwitchUserListener" class replicates some of the code in the original handling (well, the whole class) and updates the "attemptSwitchUser" method to check the user they're trying to switch to and see if they have the right role. Finally he shows how to add it to the services configuration and how it overrides the default listener.

On PHPMaster.com today they've posted the first part of a series spotlighting Openbiz Cubi, a PHP "framework" with a business focus.

Openbiz Cubi is a robust PHP application framework giving developers the ability to create business applications with minimal effort. In this two-part series I’ll explain the concepts and steps necessary to create your own business web applications with Cubi. We’ll look first at the challenges web developers face and how Openbiz Cubi can help, and then how to install Cubi. In part 2 we’ll see how to create our own modules.

They start off by describing the tool and some of the features that come with it (including user management and the XML data object structure). Complete installation instructions are included and a screenshot is included of the end result. They include a "quick tour" of Cubi's features and some of the modules that come with it like the System, Menu and User modules. In part two of the series, they'll show you how to create a custom module.

In this recent post to his site, Rafael Dohms presents an interesting idea for leaders of groups to consider as a role for themselves (or people maybe wanting to move into something like that) - being an "enabler" instead of just a "leader".

This was discussed in our PHPSP UG and we tried to think of different structures to get past these issues, some ideas came and went but I also left and moved to Amsterdam. As it happens my community-drive did not stop and I started to feel that old itch, and ended up causing the start of AmsterdamPHP. [...] So we do not have leaders, we just have a group of enablers, people who want to help, or do, or have great ideas or contacts, and that seems to be a great title and description for what we are doing. It removes those misconceptions and it opens space for anyone to be an enabler, all the time, some of the time, whenever they want. It still gives credit where credit is due and it allows the people who deserve to help the group find a direction do exactly that.

He notes that by not trying to fill the traditional conceptions of a "leader" role and being more of the "guiding people" kind of person, you can sometimes do more to help others find their passion.

I have really come to love the title and all the “meaning” it holds, maybe it even takes the pressure off the usual labels and let’s us focus on breaking down barriers.

On PHPMaster.com today there's a new tutorial posted (from Martin Psinas) about using role-based access controls in PHP-based applications. His method isn't based in any specific framework, so it's easily portable to just about any app out there.

In this article I will discuss my personal favorite approach: role based access control (RBAC). RBAC is a model in which roles are created for various job functions, and permissions to perform certain operations are then tied to roles. A user can be assigned one or multiple roles which restricts their system access to the permissions for which they have been authorized.

He starts with a warning that, if not properly maintained, a role-based system like this can get to be somewhat chaotic so a rules should be in place around the adding and removing of permissions at certain times. His functionality is based on a few database tables - roles, permissions and cross-reference tables between users/roles & permissions/roles. All of the code you'll need to implement the system is included in a Role class, the PrivilegedUser class and the methods you'll need to add/remove/check the logged in user's permissions.