Download the PHP package rpillz/laravel-feature-access without Composer

Feature access for Laravel apps

Add Plans (eg: Basic, Standard, Pro) and Feature restrictions (eg: Can Make 3 Pages, Can Upload Video) to your Laravel app.

Plans and corresponding features are hard-coded in a config file, but these defaults may be overridden with a database entry for a specific user. (ie: Your special friend who wants all the features, but, like, for free.)

Feature access can be assigned to any model (eg: User, Team) via a trait, which adds properties to use in your app logic, such as $user->canViewFeature('pictures-of-my-dog')

Installation

You can install the package via composer:

Publish the config file. This is where your features and tiers are defined.

Publish and run migrations. This will create a 'features' table for storing access information attached to your models.

Basic Usage

1. Define Features (and Tiers) in the Config

Start by defining your app features in the feature-access.php config file.

This is an example of a feature mapped out in the config file:

The base level of this feature will be the permission used for all users and guests unless they have been explicitly granted an upgraded access level, or override.

2. Add Trait To Model

In most cases, you would add this trait to your User model, which would allow that user to access (or not access) features.

3. Add Permission Checks to your App Logic

An example, in a blade template, of adding a button to create a new item, only if the current user is allowed to create on the feature sample-feature.

4. Grant Higher Access To Users

You can set permission acces for your User (or any model) with the setFeatureAccess() method.

In the first example above, the user is granted basic level access to sample-feature. However, there is no basic level defined in the feature config file. Their permissions for sample-feature will default to the basic settings. These same default settings would be used if no level has been explicitly set for a user.

More Usage Options

Using Team Model

Your app may make use of Teams (a la Jetstream) in which case you may want to have the Team model using this trait, and accessing user permissions via their team.

Add the HasFeatureAccess trait to your Team model. Now any user on that team will have access to the same features, through the team.

This trait can be applied to any Model, or even multiple models if you want to be able apply permissions to both Users and Teams individually. (There is no built-in permission inheritance in such a case, just one or the other.)

Using Other Models

You can grant feature access to any model using the HasFeatureAccess trait. In most cases, that model would somehow be associated with the authenticated user. However, it could be adapted to other uses:

• On a Tenant or Domain model, which would grant features depending upon the domain through which your app was being accessed.
• On a particular Page or Post to change what features are displayed in the layout.

You can be using this on multiple models within the same app, so you may bend it to your will!

Methods to Check Permission On Your Model

Using The Facade

You can use the Facade methods to check permissions. However, this only works for the User and/or Team models. The upside is these will work whether or not a visitor is signed in to an account, and returns base access for guests.

If you need to get the full array of current permission access, you can use this:

Integrating with Subscriptions (from Cashier, SPark, etc.)

Rather than creating/updating duplicate database rows to change a user's feature access level, there is a feature to dynamically check the active subscription level for a user, and get the feature permissions accordingly.

This feature must be activated in the feature-access.php config file.

Then you need to add a function on your User model (or Team model, or whatever is using the HasFeatureAccess trait) which will return a name corresponding to the appropriate level, as defined in your feature config.

Once you have this set, the subscription will be consulted when returning a User's current feature access.

In order of priority, the user's feature level is first determined by anything saved in the database (by setFeatureAccesss() for example), then checking the subscription level (if activated) and finally defaulting to the config file. This means it is possible to upgrade access above and beyond a paid subscription for your VIP users on a case-by-case basis. (technically, you could also downgrade them, you monster!)

Here's an example of the function to go along with Laravel Spark subscriptions.

Notice, also, that this function accepts an optional $feature_name argument, which allows you to be more granular in your subscription and logic if needed. (ie: if the subscription to access Pages is different from the subscription to access Blogs)

Super-Admin Permission

If the current model property matches anything in the array, all permission tests will return true. They get to do everything.

Testing

Changelog

Please see CHANGELOG for more information on what has changed recently.

Contributing

Please see CONTRIBUTING for details.

Security Vulnerabilities

Please review our security policy on how to report security vulnerabilities.

Credits

• Ryan Pilling
• All Contributors

License

The MIT License (MIT). Please see License File for more information.