JosephSilber/bouncer v1.0.0-rc.2 on GitHub

New

Support for Laravel 5.7
Running after policies. 1103309

Note: this only works in Laravel 5.7+

You can now configure Bouncer to run its checks after your policy checks:
```
Bouncer::runAfterPolicies();
```
This will ensure that even if Bouncer allows a given action, you can still reject it from a policy. For example:
```
Bouncer::allow($user)->to('delete', Listing::class);

class ListingPolicy
{
    public function delete(User $user, Listing $listing)
    {
        if ($listing->isLocked()) {
            return false;
        }
    }
}
```
By default, Bouncer runs before your policies. Since deleting a listing is allowed by Bouncer, the policy is never called, and deleting locked listings is alowed for anyone who can delete listings.
By configuring Bouncer to run after your policies, you get a chance to reject a given check before it even hits Bouncer, so that no one can delete a locked listing. Since the policy does not return anything for unlocked listings, the gate will then check with Bouncer if the action is allowed.
See #264 for the history and full discussion around this feature.

Note: this will be the default (and possibly only) mode in a future version of Bouncer that only supports Laravel 5.7+. If you're on 5.7, you're strongly encouraged to enable this configuration.
Optimized checking against many abilities. #276
By default, Bouncer fetches all of a user's abilities from the DB when running an authorization check. This only happens once, with subsequent checks running against the cached abilities.
This is perfect for apps that only use a handful of abilities per user. But for apps where a single user may have 100s or even 1000s of abilities, pulling down all of that just to run a single check is not ideal.
You can configure Bouncer not to cache abilities:
```
Bouncer::dontCache();
```
Now, when running in this mode, Bouncer will not even pull down the abilities; all checks will be done directly in the database.

Fixes

Removing an ability from a user also removed it from a role with the same ID #278
Syncing roles/abilities did not account for Bouncer's scope #265

Migration

There are two in-progress features that did not make the cut for this release. Part of the groundwork did make it in, and that includes the additions to the schema. As part of this upgrade, 3 new columns were added.

If your app is not in production yet, and you don't have any real data yet:
1. Delete your existing Bouncer migration file.
2. Generate a new one with:
```
php artisan vendor:publish --tag="bouncer.migrations"
```
3. Rerun all your migrations:
```
php artisan migrate:fresh
```

If your app is already in production with real data:

Create a new migration file by running:

php artisan make:migration upgrade_bouncer_to_rc2

Open the file, and replace the contents of the up method with this:

Schema::table('abilities', function (Blueprint $table) {
    $table->json('options')->nullable();
});

Schema::table('assigned_roles', function (Blueprint $table) {
    $table->integer('restricted_to_id')->unsigned()->nullable();
    $table->string('restricted_to_type')->nullable();
});

Make a backup of your database before running the migration.
Run the migration:
```
php artisan migrate
```

A note on version compatibility

This version was supposed to drop support for older versions of PHP/Laravel, as outlined in the release notes for RC1. However, since this release includes two important bugfixes, it still supports Laravel all the way back to 5.1 and PHP all the way back to 5.5.

If there are no show stopping bugs found with this RC, the next RC will no longer support these older versions of Laravel & PHP. If you're still stuck on these older versions, you can continue using Bouncer with this release until you're ready to upgrade.