Laravel 10 adds a bool return type declaration to policy methods. How to square this with the Gate::after() approach where policy methods often return nothing?

[nathan-io]

When writing model policy methods for an application where the "Admin" role has any permission by default, we've followed the approach outlined in https://freek.dev/1325-when-to-use-gateafter-in-laravel (edit: which is provided as a reference at https://spatie.be/docs/laravel-permission/v6/basic-usage/super-admin#content-gateafter)

This boils down to: only write conditions that return true, unless we want to deny an ability even to admins in which case we return false.

And then our Gate::after() looks like:

        Gate::after(function ($user, $ability) {
            return $user->is_admin; // accessor which returns $this->hasRole(Role::Admin)
        });

So when we want to deny authorization to a non-admin, we don't need to return anything.

Starting with Laravel 10, model policy methods have a bool return type declaration. While we've removed these and things seem to be working, I would like to continue following Laravel convention if possible, especially in future projects.

I'm wondering if anyone has any thoughts on this?

In order to always return a boolean, we'd have to rewrite every policy method to include a check for admin role.

[parallels999]

Starting with Laravel 10, model policy methods have a bool return type declaration.

It was always expressed that Policies must return bool, that didn't start with 10.x, if you didn't, it means you were doing them wrong for a long time before they added

Check the documentation for Laravel 8.x, 9.x
https://laravel.com/docs/8.x/authorization#policy-methods

[parallels999]

See https://freek.dev/1325-when-to-use-gateafter-in-laravel

That is not the official Laravel documentation, it is just a blog, maybe author fails,
I followed the official documentation and everything is fine

[nathan-io]

See https://spatie.be/docs/laravel-permission/v6/basic-usage/super-admin#content-gateafter

They link to the blog post there, and the author is the lead contributor to this package.

Thank you.

[nathan-io]

See https://freek.dev/1325-when-to-use-gateafter-in-laravel

An example policy shown the "Explaining Gate::after" section:

public function administer(User $user, Event $event)
  {
     if ($user->organizes($event)) {
        return true;
     }
  }

Laravel switched from doc blocks to return type declarations in 10. That's when my IDE started complaining.

Please read the cited documentation before commenting.

[drbyte]

I've rarely used the after method, but it's on my to-do list for a project I'm working on. Haven't kicked at it yet to see what's different when being more strictly-typed within an app.

That said, Laravel's docs: https://laravel.com/docs/10.x/authorization#intercepting-gate-checks don't indicate a specific return type for bespoke Gate calls:
Gate::after example:

use App\Models\User;
 
Gate::after(function (User $user, string $ability, bool|null $result, mixed $arguments) {
    if ($user->isAdministrator()) {
        return true;
    }
});

That's when my IDE started complaining

IDE's don't always get it right. Especially if they can't trace all the way into the internals being leveraged.

[drbyte]

but ... yes ... let's figure out what the best example is so we can update the docs accordingly.

[nathan-io]

Agreed on the IDE point!

The question of return type declarations is on the model policy methods. Starting in Laravel 10, a scaffolded policy method has a bool return type declaration, where before it was just a DocBlock.

https://github.com/laravel/framework/blob/9.x/src/Illuminate/Foundation/Console/stubs/policy.stub
https://github.com/laravel/framework/blob/10.x/src/Illuminate/Foundation/Console/stubs/policy.stub

I forgot to mention that when we upgraded an existing L9 app to L10 using Laravel Shift, we started getting exceptions because Shift had added return type declarations to the policies.

Removing the return type declarations from our policy methods resolved the exceptions, and everything seems to be working fine since.

Some of our policy methods are empty. Others will return either true (only a subset of users are authorized) or else not return anything. Others will either return false (even a super-admin isn't authorized) or nothing.

We've been using this approach in conjunction with a super-admin check in Gate::after() to avoid having to write "is super-admin" checks everywhere, and authorization seems to all be working as expected.

---

The Laravel docs only seem to discuss model policies returning either a boolean or an Illuminate\Auth\Access\Response, but apparently it's safe to return nothing sometimes?

I just wonder if there's potential for some sort of unexpected behavior somewhere by doing this.

Something to note is that if you use artisan make:policy starting in Laravel 10, and follow that example of a policy which sometimes doesn't return a bool, you'll get an exception. More an annoyance than anything, as it's no big deal to remove the type hint (edit) change or remove the return type declaration.

[drbyte]

Something to note is that if you use artisan make:policy starting in Laravel 10, and follow that example of a policy which sometimes doesn't return a bool, you'll get an exception. More an annoyance than anything, as it's no big deal to remove the type hint.

Ya, I suspect there's likely a bunch of discussion going on in the Laravel community about such mismatches. It'd be interesting to see what advice is given, and workarounds recommended.

[drbyte]

With middleware and policies I've often seen/heard it said (docs, articles, laracasts, other videos) that returning true/false ends the cascading lookups by returning that boolean. But if you return null (which also effectively happens if don't return anything), then it falls down through to the next check in the cycle ... whether the next defined middleware, or the next layer of checking such as bespoke Gate declarations, Policies, and other AuthServiceProvider rules, etc.

So, yes, it's always been "3 types of valid returns" (bool or null), plus Response was added as a 4th.

I'm curious to see what's being recommended now that stricter typing is implemented in the stubs used for generating. Perhaps they need to simply allow null in the declarations?

[nathan-io]

But if you return null (which also effectively happens if don't return anything), then it falls down through to the next check in the cycle ... whether the next defined middleware, or the next layer of checking such as bespoke Gate declarations, Policies, and other AuthServiceProvider rules, etc.

This is how I assumed it worked. I do wonder what happens if neither the model policy method nor Gate::after() return anything. Perhaps Laravel falls back to false in this case?

Of course, the Gate::after() approach shown at https://spatie.be/docs/laravel-permission/v6/basic-usage/super-admin#content-gateafter always returns true or false, which presumably negates any risk of not returning something from the policy method.