PHPackages                             jellis/check - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Authentication & Authorization](/categories/authentication)
4. /
5. jellis/check

ActiveLibrary[Authentication & Authorization](/categories/authentication)

jellis/check
============

A very easy-to-implement user access control package designed for use with Laravel and Eloquent

v0.2.6(9y ago)240MITPHP >=5.4.0

Since Jan 24Compare

[ Source](https://github.com/jellis/check)[ Packagist](https://packagist.org/packages/jellis/check)[ Docs](https://github.com/jellis/check)[ RSS](/packages/jellis-check/feed)WikiDiscussions Synced 4w ago

READMEChangelogDependencies (2)Versions (9)Used By (0)

NOTE
====

[](#note)

Ensure you don't use the RoutAwareModel for your Authenticatable User model - it becomes a circular operation when applying the global scopes and you'll get a bad gateway (502) error.

What's it all about?
--------------------

[](#whats-it-all-about)

The purpose of the project was to create a syntactically simple way to implement context-based user access control. What does that mean, exactly? Good question...

### Context-based access control

[](#context-based-access-control)

I wanted to start with the idea that I could use a really straight-forward syntax for my "things" (whatever they might be). The first concept I came up with was `Check::can('post.edit')`. Because I was a fan of naming my routes, this made good sense from a flow point-of-view. Because I have my routes named, I figured I'd be able to implement middleware that would also leverage the access control system.

Adding context to the access control wasn't a trivial task. Each model will have its own context. Say in a `Post` model, "owning" a post might mean that there is a `user_id` field on the `Post` that is equal to the current user, but in a `User` model, "owning" might mean that users are in the same company as you. So, how do I have a simple syntax for implementing and checking permissions, but also giving context when the need arises?

Using the Jeffrey Way school of thought, I started with how I wanted to define things... I really wanted my `Role` classes to be so simple it's almost stupid.

```
    $permissions = [
        'post' => [
            'index', 'create', 'store', 'view', 'edit:own', 'update:own',
        ]
    ];
```

After starting with those two ideas, I set to work and actually managed to implement them. What we have is, I think, a simple, fluent way of managing user access.

### Route Aware Models

[](#route-aware-models)

If you have, say, a listing page for your users where they can see all posts, but can only edit their own, you'd simply have to do the following.

Register the service provider config/app.php

```
    'providers' => [
        ...
        Jellis\Check\Providers\CheckServiceProvider::class,
        ...
    ],
```

Register the facade in config/app.php

```
    'aliases' => [
        ...
        'Check' => Jellis\Check\Facades\Check::class,
        ...
    ],
```

Name the route and assign the middleware

```
Route::get('post', ['uses' => 'PostController@index', 'as' => 'post.index', 'middleware' => 'check']);
```

Create a role (assuming "member" for this user)

```