On the Laravel News site they highlight a change in the way that the "gates" handling works in the v5.7 release of the popular framework. In this change you can now allow "guest" users into certain parts of your system.

In Laravel 5.6 and below authorization gates and policies automatically return false for unauthenticated users. New in Laravel 5.7, you can now allow guests to go through authorization checks by using a nullable type-hint or setting the default value as null:

[...] By using a nullable type hint the $user variable will be null when a guest user is passed to the gate, and you can then make decisions about authorizing the action. If you allow nullable types and return true, then the guest will have authorization.

The post includes a code snippet showing how to put it to use and the resulting 403 page they would get otherwise. You can find out more about other new features of Laravel v5.7 in this other article.

On the TutsPlus.com site there's a new tutorial posted for the Laravel users out there covering a few pieces of the authorization features of the framework. The tutorial covers "gates" and "policies", introducing some of their basic concepts and providing example code to implement your own.

Today, we're going to discuss the authorization system of the Laravel web framework. The Laravel framework implements authorization in the form of gates and policies. After an introduction to gates and policies, I'll demonstrate the concepts by implementing a custom example.

I assume that you're already aware of the built-in Laravel authentication system as that's something essential in order to understand the concept of authorization. Obviously, the authorization system works in conjunction with the authentication system in order to identify the legitimate user session.

The article starts by introducing some of the basic approaches the framework takes to authorization handling and where gates and polices fit in. It then gets into the details of each including example code showing how to define them based on the interfaces provided. The tutorial then shows how to put them to use in a simple application, applying them at both the controller and view level.

On the Pineco.de site there's a tutorial posted showing you how to implement the Laravel auth system on the frontend re-using the same logic in a single-page Vue.js application as you would on the backend.

If you are using Laravel, probably you are familiar with its ACL. You can easily restrict user’s access by creating policies and binding them to the specific models. It works perfectly on the back-end, but what can we do if our app is something like an SPA?

The post starts with a brief overview of the Laravel ACL handling as it relates to users and policies about what they can do or access. The frontend setup then makes use of a "cheap copy" of the Laravel "gate" handling via a Javascript-based request. They walk you through the preparation work you'll need and the creation of a gate class to define the current policies for CRUD methods. The main "Gate" class is then defined, setting up the before, allow and deny action methods. Finally these pieces are integrated into the Vue.js application with an example of either showing or hiding the "Edit" link based on the user permissions.

On the Pineco.de site there's a tutorial posted showing you how to implement the Laravel auth system on the frontend re-using the same logic in a single-page Vue.js application as you would on the backend.

If you are using Laravel, probably you are familiar with its ACL. You can easily restrict user’s access by creating policies and binding them to the specific models. It works perfectly on the back-end, but what can we do if our app is something like an SPA?

The post starts with a brief overview of the Laravel ACL handling as it relates to users and policies about what they can do or access. The frontend setup then makes use of a "cheap copy" of the Laravel "gate" handling via a Javascript-based request. They walk you through the preparation work you'll need and the creation of a gate class to define the current policies for CRUD methods. The main "Gate" class is then defined, setting up the before, allow and deny action methods. Finally these pieces are integrated into the Vue.js application with an example of either showing or hiding the "Edit" link based on the user permissions.

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.