Model Policies and Relationships

@vincent15000 I haven't actually written any code yet, just planning it out.

They're not static methods, despite writing the post using '::' notation. I've switched to arrows below.

The initial approach would result in methods like ProjectPolicy->addTask(User $user, Project $project, Task $task). The parent model's (Project) policy references the child model Task. This was an attempt to literally recreate the other codebase's implementation.

The approach I now think is more proper in Laravel would result in TaskPolicy->create(User $user, Project $project). This keeps policies more self-contained and more closely aligned with their models. It also seems to result in less code that is simpler.

The question is what methods belong in which model policy, not whether the the methods are static.

@Caraes_Naur

The question is what methods belong in which model policy

Basically what the current logged in user with role can do (or cannot).

• update
• create
• etc

I use a role based technique myself. Checking if the users role (one of their roles) matches a required role:

    public static function chkRole($role = null)
    {
        $userrole = Auth::user()->role;
        $checkrole = explode(',', $userrole);
        if (in_array($role, $checkrole)) {
            return true;
        }
        return false;
    }

Rather than a related table of roles, I use a simple comma separated list.

For example I may have for a user:

admin,bkeep,user

bkeep is for bookkeeper. But for your question it's what the user can or cannot do.

@martinbean also has a technique in a blog:

https://martinbean.dev/blog/2021/07/29/simple-role-based-authentication-laravel/

You need to ensure that a id isn't changed in the query string also, by using auth::id.

    public function getPets($query, $petsearch = '')
    {
        $petsearch = $petsearch . "%";
        $query->where('petname', 'like', $petsearch);
        if (ChkAuth::chkRole('admin') === false) {   // custom code
            $userid = Auth::user()->id;
            $query->where('ownerid', '=', $userid);
        }
        $results = $query->orderBy('petname', 'asc')->paginate(5);
        return $results;
    }

So if admin show all, otherwise show only current users. You have to strategically write queries that include security (protection from tampering with the url query string).

Otherwise a user can change an id from 1 to 55 for example.

Above just examples.

In the 30 days to learn laravel FREE video course, @jeffreyway covers gates and policies.

@jlrdw But your static function isn't in the policy class, it's just a helper, isn't it ?

@vincent15000 Yes,I write my own authorization but still use laravels authentication.

@jlrdw This reminds me how I did for my policy.

For example if I have a policy for the Endpoint model, but the creation or the update of the endpoint depends on the Branch model (an endpoint has a connection which has a branch).

Endpoint : id, name Branch : id, name Connection : id, name, endpoint_id, branch_id

What a user can do on an endpoint (create, update, delete) depends only on his rights on the branch in which the endpoint is connected.

Here is a small example of how I have written the policy

// EndpointPolicy

public function update(User $user, Endpoint $endpoint)
{
	return $user->isOwnerOf($endpoint->connection->branch);
}

How would you write the policy in this case ?

@vincent15000 something like:

User or admin can edit

    public static function chkUserId($userid)
    {
        if ($userid === Auth::user()->id || self::chkRole('admin') === true) {
            return true;
        }
        return false;
    }

Or if only user can edit:

    public static function chkUserId($userid)
    {
        if ($userid === Auth::user()->id) {
            return true;
        }
        return false;
    }

Or this check can also be done in controller method with a redirect if false.

@jlrdw Ok so for editing an endpoint, you don't apply the endpoint policy but a totally different policy / check.