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 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.

Matt Stauffer has continued his series looking at Laravel 5.1 with a new post covering the ACL functionality recently added in 5.1.1. This functionality adds on to the pre-existing authentication handling that has been a part of the framework for a while.

The authentication that Laravel provides out-of-the-box makes it simple to get user signup, login, logout, and password resets up and running quickly and easily.

But if you needed to control access to certain sections of the site, or turn on or off particular pieces of a page for non-admins, or ensure someone can only edit their own contacts, you needed to bring in a tool like BeatSwitch Lock or hand-roll the functionality, which would be something called ACL: Access Control Lists, or basically the ability to define someone's ability to do and see certain things based on attributes of their user record. Thankfully, Taylor and Adam Wathan wrote an ACL layer in Laravel 5.1.11 that provides this functionality without any added work.

He talks about the main interface to the ACL system, the Gate class/facade, and gives a simple example of it in use. He then gets into how it works in defining abilities and checking access levels with both the facade and on the model level. He also shows how to use the checks in Blade templates and how to intercept the evaluations for custom evaluation. He ends the post talking about the concept of policies and controller authorization to allow for additional checking.

On the Liip blog today Jean-Christophe Zulian shares an idea about gaining performance in your access controlled section of your application. He suggests preloading ACL information in Symfony2-based applications.

Symfony2 comes with an ACL mechanism that can help you whenever you need to add some permissions in your system. [...] Unfortunately we came across a situation where we had to do this kind of permission check on a very long list of items. [...] erformance will go bad (or very bad in our case) and as the system keep storing more and more of the same kind of data it become slower and slower. [...] Luckily for us Sf2 ACL system provides a way out of this. You can in a small amount of query load all the ACLs that are related to some given objects.

He includes a small snippet of code that takes in a set of blog posts (as an example) and calls a "findAcls" method to pre-fetch the information. That information is then available for the rest of the request. The fetch is done by packet instead of via one large query, making it a bit more performant.

Rob Allen has posted a technique for integrating the BjyAuthorize, a helpful module for access control in your Zend Framework 2 application, with the ZendNavigation module for user permissions-based navigation updates.

If you are using BjyAuthorize for ACL configuration and want to use ZendNavigation's ZendAcl integration features, then you need to set the Acl and Role information into ZendNavigation.

He includes the code you'll need to add to both the bootstrap of your application and the configuration to set up the "rule_providers" and "resource_providers". Then you can update your navigation settings to include "resource" and "rule" options to define with options a user can see.

Joshua Thijssen has a new post to his blog looking at a method for setting up ACL rules in fixtures for your Symfony2-based applications.

Doctrine’s DataFixtures are a great way to add test data to your application. It’s fairly easy to get this going: Create a fixureLoader that extends DoctrineCommonDataFixturesAbstractFixture, had a load() method and off you go. However, sometimes you want your data also to be protected by Symfony 2′s ACL layer. Since there isn’t a common way to do this, here is one way on how I implemented this.

His method uses the ContainerAware interface on the fixture loader instance to be able to get at the container for the fixture. This allows you to use the usual ACL handling methods of the framework to provide restrictions based on things like usernames and roles.

On Developer.com there's a recent tutorial showing you how to create a basic access control list in PHP (not in any specific framework). It allows you to define not only user permissions but groups and group permissions as well.

So, what are the advantages of an ACL model? The first advantage is security. Using this model will make your application more secure and less vulnerable to exploits. When securing any program, it is good to give to the user only the privileges he/she needs. That means that, for example, you should not give super administrator privileges to someone who will only manage website content. The ACL security model allows you to do just that. The second advantage is the easiness of user management. You can divide users into groups, while each group has certain access permissions. Also, you can easily add new user groups, delete the old ones or change group permissions.

They include the database structure you'll need to make the backend work (four tables) and the code to create an "Acl" class with methods to check a user+group for a permission, get the permissions for a user and get the permissions for a group. It's a pretty simple system and has a lot more that could be added to it to make it more robust, but it's a good start.

On the Refulz blog they've posted the next in their series about access control in CakePHP applications. In this new article they look at Access Request Objects (AROs) and Access Control Objects (ACOs) and how they can be managed via the built-in ACL functionality.

Continuing with Access Control Lists, we will read about the two Access Control Lists and their mapping. The Access Request Objects (AROs) are a list of the things that seek permissions and the Access Control Objects (ACOs) are the resources on which permissions are required. Both the lists are maintained in the tow tables, namely aros and acos respectively.

Included in the post is the SQL you'll need to create the tables for the system to use as well as some basic code to use the AclComponent with the ACOs/AROs. They also show how to use the parentNode method to create parent/child relationships between the objects.

Fuel framework users have another option when it comes to user authentication management in their applications. Ando has released Warden, a package that manages logins, password hashing and user ACLs.

Warden is a user database authorization package for the FuelPHP framework that aims to fast track development by handling the work load of uthenticating user's. Built for performance, it comes with a ready-to-use user model and database install script.

The package uses bcrypt for password hashing and also provides features for forgotten passwords, password resets and "remember me" functionality. Installation is as simple as adding it to your "always_load" package list and setting up a few configuration options. Sample code for its features is included. You can get the latest version directly from github.

On NETTUTS.com today there's a new detailed tutorial on how to use the access control list functionality that comes with the CakePHP framework.

If you’re building a CMS, you'll probably need different user roles—superusers, admins, users - with different permission levels. Too complicated to code? Enter CakePHP's ACL (Access Control Lists). With the right setup, you’ll be checking user permissions with just one line.

They talk about what "access control lists" are but shows you an example of one including the database tables and the full scripts for the Users controller, a model to hook into the database and the view for output to the user. They include methods for denying access, checking permissions, and modifying a user's permissions.