In a post to his site Adelf aims to help you answer the question of the use of either the Entrust or Laravel-permission packages in your Laravel application to handle your authorization.

"Hmmm, I need some basic authorization, like admin role for admin panel and maybe some editor/moderator role... Let's google it. Wow! Laravel already has packages for that! zizaco/entrust, spatie/laravel-permission and others! Let's choose one!"

That's how it usually happens. Then package's migration will add about 5 tables to store roles, permissions and their relations. [...] It only looks simple: just install package, run ready migration and go on. From long-term point of view for 90% projects it's not the best choice.

He starts with an example of a common situation for most web developers: the inclusion of the package, the database changes that come with it and the management of keeping the permissions in sync. He makes the suggestion that maybe this seemingly "simple" way may not be the best and that, in most cases, they're overkill for what an application needs. He shows how to slim down this functionality using Laravel's own gates/policies and boil it down to just the checks that need to be made without the package overhead.

Alison Gianotto has an article posted to her since basically answering the "now what?" question resulting from you running Composer as root on your system.

Composer is a PHP dependency manager that’s used in just about any modern PHP application, and it works similarly to how Bundler works for Ruby.

Even though Composer itself gives you a warning about not running it as root, lots of people disregard this warning and run it as root anyway. We run into this issue a lot on my open source asset management project, Snipe-IT, so I figured I’d write up how to fix this if you inadvertently (or advertently) ran composer as root.

She starts by describing the difference between "installing Composer as root" and "running the Composer install as root" (two very different things). She points out that, while Composer tries to prevent the second but permissions errors sometimes cause people to move forward as root anyway, despite the warning. She then shows how to fix the permissions issues so it can be run as a normal user, updating the files in .composer for the root account and re-running the install.

In a post to the SitePoint PHP site editor Bruno Skvorc wonders if bitwise operators are still relevant in modern PHP development.

Many of you probably scratched your heads reading this title. “Bitwhat?”

In this article, we’ll look at what bitwise operators are, and whether or not their use is still relevant in this modern age of computing.

He starts off by illustrating a common use case for the bitwise operators in evaluating user permissions. He first proposes doing things on the database side, creating tables for double or single joins that could get us the information we need. He also shows an approach for what he calls a "column stampede": adding a new column to the user table when a new permission is needed. Instead he proposes the bitwise option, first explaining how values are stored and then showing how with a single value, you could potentially store all of a user's permissions in one field. Next he shows how to perform the select to determine of a user has a set of permissions and how to store them when making an insert/update.

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.

In the latest release of the Laravel framework (v5.1.1) they've introduced authorization handling to the native framework. This allows you to integrate permissions checks and perform policy validation both on the backend and in the templates.

In addition to providing authentication services out of the box, Laravel also provides a simple way to organize authorization logic and control access to resources. There are a variety of methods and helpers to assist you in organizing your authorization logic.

The functionality includes the concepts of "abilities" (permissions, essentially) and validate the allow/deny status based on object properties, such as Users. The documentation shows how to perform the evaluations in the controllers, user model, form requests and even in the Blade templates. There's also a section on creating policies for more complex evaluations than just one-off permission checks.

To get a feel for what the community things of this new functionality, be sure to check out this Reddit thread with feedback, both positive and negative, on how it was implemented.

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

On her blog today Lorna Mitchell talks about a problem she encountered with the Magento web API interface - an "Access denied" message that was keeping her out.

I've been working with the Magento Web API lately, and the first problem I ran into was actually getting access to it. Contrary to its reputation, I found some perfectly good documentation outlining how to connect to the service and use it.

A search for a fix to her "access denied" message lead her to this forum post talking about web service permissions and how it relates to user setup. An API key and username are needed to work with the API and can be set up in the user's information.