JosephSilber
Repos
40
Followers
592

Eloquent roles and abilities.

3117
312

Caches responses as static files on disk for lightning fast page loads.

1031
108

Renders client templates from separate files into the main view of your application

12
1

Sanitize user data before passing it on to validation/persistence.

2
1

Events

issue comment
Multiple Database Connection

Bouncer uses JOINs extensively, which means that all tables must reside in the same DB.

Created at 1 week ago
issue comment
Teams Permissions

Teams are basically the same concept as multi tenancy:

https://github.com/JosephSilber/bouncer/blob/master/readme.md#multi-tenancy

Set the team_id as the current scope, and any role/permission granted will be specific for that team. Same for checks: any checks at the gate will be specific to that team.

Created at 3 weeks ago
closed issue
Super bummed to see levels removed

I'm just getting around to updating my app I just realized that levels were removed from Bouncer. That's a big shame. They were one of the best unique features of this package compared to other acl packages. :(

Created at 3 weeks ago
issue comment
Super bummed to see levels removed

I can definitely see where you're coming from, especially since you've already implemented it in your app.


It was removed because the maintenance burden was just too big, and it really prevented many different features. It's also tricky to reason about when you add forbidden abilities into the mix. It was a constant source of confusion for anyone trying to use it.

I wasn't sure about it originally, which is why I never documented it.


Hierarchical levels make more sense to live within your codebase. Wherever you manage abilities, you should also grant/revoke them to the roles with higher/lower levels, as you see fit.

Created at 3 weeks ago
pull request closed
Feature/sn 651 improve page cache
Created at 1 month ago
issue comment
Feature/sn 651 improve page cache

Thanks for your interest, but this is way more complexity that I'm willing to take on for this simple package.

Created at 1 month ago
issue comment
OwnedVia does not work

Sorry for not having an answer yet. It's summer. I checked it out and started playing with it, but didn't have time to fully dig in yet.

Just checking in with to say that I didn't forget, and thanks for the reproduction.

Created at 1 month ago
issue comment
Owning A Model

You have to first tell Bouncer that users may own leads:

Bouncer::allowEveryone()->toOwn(Lead::class);
Created at 2 months ago
issue comment
Cache performance inefficent
  • Each ability check sets a new key in cache for every single user

    Of course it does! How else could it be stored? It's obviously user-dependent, so it has to be stored per user.

  • Each of the checks sets a huge payload in your cache, e.g. Redis, which has a serialized model of every single ability defined

    I actually had a plan to introduce an additional caching strategy which only caches Boolean responses to a given check. It would use the non-caching Clipboard (currently activated by using Bouncer::dontCache()), and simply cache the returned Booleans.

    I had started on it once, but didn't finish it. I said in #276:

    After merging this and having people try it out, I plan to create an additional caching clipboard based on this one, that only caches the results of the checks at the gate.

    If we want to revive that, we would have to figure out a way to make all of this configuration intuitive:

    • Should we cache at all?
    • Should we only cache for the current request?
    • Should we only cache for the current request single abilities at a time?
    • Should we cache for future requests?
    • Should we only cache for future requests single abilities at a time? If so, should we cache for the current request all abilities?

    To complicate matters, we might even need another layer of local caching. As you can see here, here and in other places, rehydrating all models for every check is quite wasteful, so a local cache would be really beneficial.

    This gets really complex. Add in expiration to the mix, and it can get really hairy.

  • The cache is set forever which is not recommended, because there's potential the cache would never get cleared and linger around forever. There should be a reasonable limit, e.g. 1 month.

    I can hear that. It's been requested in #552, and I think it makes sense to make it configurable.

    Would only be complex if we would have two layers of caching (see the previous point).

Created at 2 months ago
reopened issue
OwnedVia does not work

I want to be able to own a specific model via the ownedVia method you have in your documentation.

Now I am declaring the ownedVia method in the AppServiceProvider boot() method like this

Bouncer::ownedVia(Application::class, static function ($application, $profile) {
    Log::debug('closure run', ['profile' => $profile]);
    Log::debug('Query: ', ['result' => $application->whereHas('profiles', function (Builder $q) use ($profile) {
        $q->where('profile_id', '=', $profile->id);
    })->count() > 0]);
    return $application->whereHas('profiles', function (Builder $q) use ($profile) {
        $q->where('profile_id', '=', $profile->id);
    })->count() > 0;
});

Now I will attach an application to a profile so there is a relationship.

Now if I do the following: $profile->can('edit', $application) it should return true, right? But this will return false. If we look at the log statements I added in the ownedVia method, we see that the result of the query return true, so that is what we expect.

Do you know why the $profile->can(...) statement does not work?

Created at 2 months ago
issue comment
OwnedVia does not work

I see this in your seeder class:

Bouncer::ability()->firstOrCreate([
    'name' => 'view',
    'title' => 'View'
]);

Bouncer::ability()->firstOrCreate([
    'name' => 'create',
    'title' => 'Create'
]);

Bouncer::ability()->firstOrCreate([
    'name' => 'update',
    'title' => 'Update'
]);

Bouncer::ability()->firstOrCreate([
    'name' => 'destroy',
    'title' => 'Destroy'
]);

What is that? view/create/update/destroy on their own don't do anything. They have to either be connected to a model, or explicitly be set to to apply on all models.

It is generally advisable to always use Bouncer's own allow (etc.) methods, since that'll set the correct attributes on the abilities.

Created at 2 months ago
pull request closed
Create PHPDoc in BouncerFacade

Motivation

Currently, I use Visual Studio Code, and as the facade does not have phpdoc, intellisense cannot identify the methods that are available on the facade.

image

However, when phpdoc is added to the facade, intellisense shows the available methods.

image

So, I decided to add PHPDoc on the facade.

Created at 2 months ago

added phpdoc in facade (#599)

Created at 2 months ago
issue comment
OwnedVia does not work

That should definitely work.

Can you create a small isolated reproduction repo?

Created at 2 months ago
closed issue
OwnedVia does not work

I want to be able to own a specific model via the ownedVia method you have in your documentation.

Now I am declaring the ownedVia method in the AppServiceProvider boot() method like this

Bouncer::ownedVia(Application::class, static function ($application, $profile) {
    Log::debug('closure run', ['profile' => $profile]);
    Log::debug('Query: ', ['result' => $application->whereHas('profiles', function (Builder $q) use ($profile) {
        $q->where('profile_id', '=', $profile->id);
    })->count() > 0]);
    return $application->whereHas('profiles', function (Builder $q) use ($profile) {
        $q->where('profile_id', '=', $profile->id);
    })->count() > 0;
});

Now I will attach an application to a profile so there is a relationship.

Now if I do the following: $profile->can('edit', $application) it should return true, right? But this will return false. If we look at the log statements I added in the ownedVia method, we see that the result of the query return true, so that is what we expect.

Do you know why the $profile->can(...) statement does not work?

Created at 2 months ago
issue comment
OwnedVia does not work

maybe a good idea to also include this in the documentation?

This has been documented since the beginning:

https://github.com/JosephSilber/bouncer#allowing-a-user-or-role-to-own-a-model

Created at 2 months ago
issue comment
OwnedVia does not work

The ownedVia method simply sets up the logic. You still must tell Bouncer that a profile is allowed to own an application.

In your seeder (or wherever you set up your DB-based permissions), add the following:

Bouncer::allow(Profile::class)->toOwn(Application::class);

This says that any profile that owns an application can do everything with that application.

Now, when the gate checks will actually run, your closure will be consulted to determine whether the given application is owned by that profile.

Created at 2 months ago
closed issue
Bouncer::can does not work at all

Bouncer::can does not work at all

Created at 2 months ago
issue comment
OwnedVia does not work

Your question is not very clear. Can you please try to post again with a little more clarity?

Created at 2 months ago