You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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):
Test:
Expectation:
false
Result:
true
The text was updated successfully, but these errors were encountered: