Laravel 5 is trying to steer away from the filters.php file and more towards using middleware. Here is an example right from the access routes file of a group of routes that requires the Administrator role:

Route::group([
	'middleware' => 'access.routeNeedsRole',
	'role' => ['Administrator'],
	'redirect' => '/',
	'with' => ['error', 'You do not have access to do that.']
], function()
{
    Route::group(['prefix' => 'access'], function ()
    	{
    		/*User Management*/
    		Route::resource('users', 'Backend\Access\UserController');
    	});
});

The above code checks to see if the currently authenticated user has the role Administrator, if not redirects to / with a session variable that has a key of message and value of You do not have access to do that.

The following middleware ships with the boilerplate:

• access.routeNeedsRole
• access.routeNeedsPermission
• access.routeNeedsRoleOrPermission

The controller middleware supports all of the same parameters as the route middleware, except that it is declared in the constructor of the controller you are trying to protect:

For example, the Route::group example above would be this:

public function __construct() {
	$this->middleware('access.routeNeedsRole:{role:Administrator::redirect:/::with:error|You do not have access to do that.}');
}

Notes: Because the new route middleware parameters in 5.1 don't support arrays, I made my own syntax.

• It uses a single parameter encapulated in brackets {}
• role can be single role:Administrator or an "array" role:Administrator|User|Other
• Same for the permissions parameter: permission:user_permission or permission:user_permission|other_permission
• The session message is in format with:variable_name|message
• The parameters are separated by a double colon :: (I did try a comma, the interpreter wasn't allowing it)

• middleware => The middleware name, you can change them in your app/Http/Kernel.php file.
• role => A string of one role or an array of roles by name.
• permission => A string of one permission or an array of permissions by name.
• needsAll => A boolean, false by default, that states whether or not all of the specified roles/permissions are required to authenticate.
• with => Sends a session flash on failure. Array with 2 items, first is session key, second is value.
• redirect => Redirect to a url if authentication fails.
• redirectRoute => Redirect to a route if authentication fails.
• redirectAction => Redirect to an action if authentication fails.

If no redirect is specified a response('Unauthorized', 401); will be thrown.

If you would like to create your own middleware, the following methods are available.

Note: A helper method access() is also available. E.g. access()->hasRole('Administrator') which resolves the Access facade out of the IoC container. You can modify this function to add more functionality in app/helpers.php.

/**
	 * Checks if the user has a Role by its name.
	 * @param string $name
	 * @return bool
*/
Access::hasRole($role);

/**
	 * Checks to see if the user has an array of roles, and whether or not all must return true to authenticate
	 * @param array $roles
	 * @param boolean $needsAll
	 * @return bool
*/
Access::hasRoles($roles, $needsAll);

/**
	 * Check if user has a permission by its name.
	 * @param string $permission.
	 * @return bool
*/
Access::can($permission);

/**
	 * Check an array of permissions and whether or not all are required to continue
	 * @param array $permissions
	 * @param boolean $needsAll
	 * @return bool
*/
Access::canMultiple($permissions, $needsAll);

Access:: by default uses the currently authenticated user. You can also do:

$user->hasRole($role);
$user->hasRoles($roles, $needsAll);
$user->can($permission);
$user->canMultiple($permissions, $needsAll);

If you would like to take advantage of the methods used by Access's route/controller handler, you can use it:

`use App\Services\Access\Traits\AccessParams`

Which will give you methods in your middleware to grab route assets or controller parameters. You can then add methods to your middleware to grab assets that access doesn't grab by default and take advantage of them.

Note: If middleware is applied to both the controller and a route group, the controller will take precedence.

Access comes with @blade extensions to help you show and hide data by role or permission without clogging up your code with unwanted if statements:

@role('User')
    This content will only show if the authenticated user has the `User` role.
@endrole

@permission('can_view_this_content')
    This content will only show if the authenticated user is somehow associated with the `can_view_this_content` permission.
@endpermission

Currently each call only supports one role or permission, however they can be nested.

If you want to show or hide a specific section you can do so in your layout files the same way:

@role('User')
    @section('special_content')
@endrole

@permission('can_view_this_content')
    @section('special_content')
@endpermission

You can add more extensions by editing app/Blade/Access/AccessBladeExtender.php

The Laracast PHP to Javascript Transformer is included in this project. The config file is published as config/javascript.php

By default the javascript variables are binded to frontend.layouts.master view file, so you can bind javascript to any method in any frontend controller.

If you need binding available in both frontend and backend controllers you should make a super master layout, and use the frontend/backend master layouts as children. After that you can specify that layout in the javascript.bind_js_vars_to_this_view config option.

A javascript() helper has been added globally so you do not have to include any files in your controllers, you may just do:

javascript()->put([
	'test' => 'it works!'
]);

There is an example in FrontendController@index and is printed out in frontend.index