[5.7] Allow Gate::after() callbacks to provide a result#24935
Merged
taylorotwell merged 1 commit intolaravel:masterfrom Jul 30, 2018
Merged
[5.7] Allow Gate::after() callbacks to provide a result#24935taylorotwell merged 1 commit intolaravel:masterfrom
taylorotwell merged 1 commit intolaravel:masterfrom
Conversation
8fc253e to
44c3390
Compare
Contributor
|
@JosephSilber am I correct in observing that the Laravel Docs for 5.7 need updating to reflect this change to |
Contributor
Author
|
Good catch. That has to be changed now.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
For example, imagine we wanted to grant admins every ability. But locked posts can't be edited by anyone, even an admin. They have to first be unlocked (this is just a trivial example).
Registering a general
beforecallback (withGate::before()), there's no way to accomplish this. Instead, we can do it via anaftercallback:With this in place, any ability that was not granted by a policy et al will be granted here for admins, while still being able to explicitly return
falsefrom any policy method to disallow it for everyone (of course, the user would have to be careful to generally not returnfalsefrom policies. Only when they want to deny everyone explicitly).My main motivation for this is for use in Bouncer, where we currently run all of our DB permission checks in a
beforecallback. This works great, but means that policies no longer work, because the call is intercepted by Bouncer in many cases.Instead, we would love to be able to register our logic as an
aftercallback. This way, the policies can all run and do their thing. If any of them return a non-nullresult, that would be used. Otherwise, Bouncer will run its checks.You can read more about our need for this in this discussion: JosephSilber/bouncer#264, specifically this comment.