Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revoking wildcard permission #1593

Closed
mohsenyz opened this issue Oct 18, 2020 · 2 comments
Closed

Revoking wildcard permission #1593

mohsenyz opened this issue Oct 18, 2020 · 2 comments
Labels

Comments

@mohsenyz
Copy link

Is it possible to have some exceptions while defining wildcard permissions?

Scenario: A user has access to all products, except product id 1
Code (Wildcard is enabled):

$user->givePermissionTo('products');
$user->revokePermissionTo('products.1');

Test:

$user->hasPermissionTo('products.1')

Expectation:

false

Result:

true
@drbyte drbyte added the support label Oct 18, 2020
@drbyte
Copy link
Collaborator

drbyte commented Oct 18, 2020

This is by design.

This package only stores and authorizes permissions/roles in an additive manner.
It does not offer "give everything and then start subtracting things".

There are many other ways to handle that sort of thing at the application level.
Usually it's best to first reconsider your approach to be "only give what they're actually allowed to do".

But if you really need to "give all first and then start subtracting", you could use Model Policies or custom Gate rules in an AuthServiceProvider.
For example, if your products model has some property that already can be used to determine that user should not have access then you could use that property to deny the user via a model policy or custom Gate rule that checks both the wildcard "all" that you first set up, and then checks the additional property to handle the denial portion of your logic.

That said, if the combination of adding-all-and-then-denying-partial permissions is crucial to your app then perhaps the Bouncer package may be a better fit for your needs.

But in my experience the practice of denying-after-over-allowing often means something should be re-evaluated in the app logic to improve its simplicity.

@spatie-bot
Copy link

Dear contributor,

because this issue seems to be inactive for quite some time now, I've automatically closed it. If you feel this issue deserves some attention from my human colleagues feel free to reopen it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants