Distinguish Access Rights to API routes with different roles

[dxL1nus]

Closes #87;

We now have a CodecheckRole class which can be extended to have our won Role Sets like e.g. ReadAccessRoles. This then gets an array of PKP\security\Role like the following:

$readAccessRole = new ReadAccessRole([
    Role::ROLE_ID_SITE_ADMIN,
    Role::ROLE_ID_MANAGER,
    Role::ROLE_ID_SUB_EDITOR,
    Role::ROLE_ID_ASSISTANT,
]);

Next an API endpoint can now have exactly one CodecheckRole Type like the following:

$this->endpoints = [
    'GET' => [
        [
            'route' => 'metadata',
            'handler' => [$this, 'getMetadata'],
            'role' => ReadAccessRole::class,
        ],
    ],
];

When the request for the endpoint is then authorized, it is checked if the endpoint role is the same as the class from each element in the $codecheckRoles array that the CodecheckApiHandler gets in its constructor. If so, then the first role element is used and its actual PKP roles are retrieved and then it is checked if the user has at least on of these roles. If so, then the route is authorized as normal.

private function getPkpRoles(string $codecheckRole): array
{
    foreach ($this->roles as $role) {
        if($role::class === $codecheckRole) {
            return $role->getRoles();
        }
    }

    throw new RoleNotFoundException("The CODECHECK Role was not found in the array of roles.");
}

and in authorize()

$pkpRoles = $this->getPkpRoles($codecheckRole);

if(!($user && $user->hasRole($pkpRoles, $contextId))) {
    $this->response->response([
        'success'   => false,
        'error'     => "User has no assigned Role or doesn't have the right roles assigned to access this resource"
    ], 400);
    return;
}

This way we can provide multiple different role sets and even create new ones, by creating new classes, which extend CodecheckRole.

[nuest]

We need to consider here that not all users may be allowed to change the status of a check.

[dxL1nus]

We need to consider here that not all users may be allowed to change the status of a check.

since these are 2 different PR's, I would firstly merge this, and then we can just use this functionality on the status branch

[nuest]

@dxL1nus Why ignore the tests?

b84d741

[dxL1nus]

@dxL1nus Why ignore the tests?

b84d741

I just did this, because this branch was so old before the rebase, that there was now test scripts in the tests directory, just the tests outcomes, which I didn't want to push of course. Now I rebase main to this branch and the gitignore is now also updated accordingly to only ignore the results in the tests directory

[nuest]

@dxL1nus will rebase this once more.

[dxL1nus]

@nuest this PR is now ready for review and can be merged if you want! Everything is now rebased to main and working