Index method removed in authorizeResource ?

[mathieutu]

Hi, just a question about resources authorization:

I've seen that the index method was removed of \Illuminate\Foundation\Auth\Access\AuthorizesRequests::resourceAbilityMap by @taylorotwell, here and I can't understand why.

Resource controllers have this method, why to remove it here ?

Thank's.

[unstoppablecarl]

To me, it looks like it was non-trivial assumption that if you can view you can also list records. An assumption that could easily be overlooked by someone using this. And overlooking it could be a big deal as this is a security issue.

It should probably have been 'index' => 'list' but, list is reserved in PHP so you cannot use it in a policy method name. If someone can come up with a reasonable non-reserved name for that ability I bet it will be added back in.

[unstoppablecarl]

Setting your own index ability is pretty clean too

class PostController extends Controller
{
    public function __construct()
    {
        $this->authorizeResource(Post::class);
    }
    
    protected function resourceAbilityMap()
    {
        return array_merge(parent::resourceAbilityMap(), ['index' => 'view']);
    }
}

[mathieutu]

Yeah of course. I know that you can overwrite it. But it fact this is a missing method here. I'll think about that and maybe try a PR...

[csiszarattila]

This hit me too.

Why not use 'index' instead of 'list'? It pretty obvious, right?

[taylorotwell]

Because typically you would limit the things you can view in your query.

[ilumos]

Building on @unstoppablecarl's snippet, repetition in every controller can be avoided by adding this to your base controller app\Http\Controllers\Controller.php:

namespace App\Http\Controllers;

use Illuminate\Foundation\Bus\DispatchesJobs;
use Illuminate\Routing\Controller as BaseController;
use Illuminate\Foundation\Validation\ValidatesRequests;
use Illuminate\Foundation\Auth\Access\AuthorizesRequests;

class Controller extends BaseController
{
    use DispatchesJobs, ValidatesRequests;

    use AuthorizesRequests {
        resourceAbilityMap as protected resourceAbilityMapTrait;
    }

    /**
     * Get the map of resource methods to ability names.
     *
     * @return array
     */
    protected function resourceAbilityMap()
    {
        // Map the "index" ability to the "index" function in our policies
        return array_merge($this->resourceAbilityMapTrait(), ['index' => 'index']);
    }
}

This allows you to write a separate policy for listing/indexing a resource, for example:

namespace App\Policies;

use App\User;
use App\RoleAssignment;
use Illuminate\Auth\Access\HandlesAuthorization;

class RoleAssignmentPolicy extends BasePolicy
{
    use HandlesAuthorization;

    /**
     * Determine whether the user can list all roleAssignments.
     *
     * @param  \App\User $user
     * @param  \App\RoleAssignment $roleAssignment
     * @return mixed
     */
    public function index(User $user)
    {
        return false;
    }


    /**
     * Determine whether the user can view a specific roleAssignment.
     *
     * @param  \App\User $user
     * @param  \App\RoleAssignment $roleAssignment
     * @return mixed
     */
    public function view(User $user, RoleAssignment $roleAssignment)
    {
        return true;
    }

And of course using authorizeResource() in each controller means no need to write lots of repetetive code!

namespace App\Http\Controllers;

use App\RoleAssignment;

class RoleAssignmentController extends Controller
{
    /**
     * RoleAssignmentController constructor.
     */
    public function __construct()
    {
        $this->authorizeResource(RoleAssignment::class);
    }

    // ....

It's not too kludgey a workaround, thanks to how Laravel's built.

[ilumos]

@taylorotwell Please consider re-adding the index method into \Illuminate\Foundation\Auth\Access\AuthorizesRequests::resourceAbilityMap so out of the box we can easily write policies that can allow or prevent listing of all of a resource's items.

I agree filtering based on authorization should be done in the query, but in many cases it's very easy to say "only admins should be able to access this resource's index page".

Sure we can currently achieve this using middleware, but why not allow authorizeResource() to be able to authorize all resource actions, instead of all but one.

Many thanks!

[hackel]

Since reserved keywords like "list" are now allowed as method names as of PHP 7, which Laravel now requires, should this issue be revisited? I'm currently using it with no ill effects.

[lasseeee]

I also tend to use @can('list', App\User::class) in blade views to hide a "Users" nav item from non-admins. Would be handy to have list in the authorizeResource array instead of having to add $this->authorize('list', App\User::class); to the index method of the UserController. Looks a little bit out of place with only the index method having this custom call, while the rest is solved by "magic".

[mjsarfatti]

None of the above methods work for me. I get 403 even if all my policy function does is return true; -

Does anybody have any idea of how to debug this?

UserController.php

class UserController extends Controller
{
    public function __construct()
    {
        $this->middleware('auth:api');
        $this->authorizeResource(User::class, 'user');
    }

    /**
     * Display a listing of the resource.
     *
     * @return \Illuminate\Http\Response
     */
    public function index(Request $request)
    {
        $this->authorize('index', User::class);

        // etc. etc.

UserPolicy.php

class UserPolicy
{
    use HandlesAuthorization;

    /**
     * Determine whether the user can list models.
     *
     * @param  \App\User  $user
     * @return mixed
     */
    public function index(User $user)
    {
        return true;
    }

    // etc. etc.

** UPDATE **

For some reason I was missing a line in app/Providers/AuthServiceProvider.php 🤦‍♂️

    protected $policies = [
        Assessment::class => AssessmentPolicy::class,
        User::class => UserPolicy::class, // <-- this was missing
    ];

[ilumos]

To add to the above, make sure you use the classes specified in the policy, as I believe the gate will silently return false if the policy classes can't be found / resolved. This has caught me out big time in the past.