You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I THINK, per this experience, that the validation test relationshipRules() is run AFTER the authorizer is run. That might be okay, it just means that the authorizer logic has to assume that required attributes or relationships might not be present or may be set to null (meaning 'no relationship'). This seems undesirable, but maybe it's important, in which case this should be well documented.
Example below, where setting the relationship "project" to null causes a fatal error "Call to a member function getId() on null in /home/vagrant/Code/hoistway-cms/app/JsonApi/Tasks/Authorizer.php:59". I can design around this by checking first, or it would be fixed if validation were performed first. Maybe there is a reason to not do that, though? Note that 'TemplateAuthorizer' is my own common auth check class, and for Tasks it has a special case so I am only overwriting the relevant test.
<?phpnamespaceApp\JsonApi\Tasks;
useApp\JsonApi\TemplateValidators;
useApp\Models\Task\Task;
useCloudCreativity\JsonApi\Contracts\Validators\RelationshipsValidatorInterface;
classValidatorsextendsTemplateValidators
{
/** * @var string */protected$resourceType = 'tasks';
/** * @var string[] */protected$allowedIncludePaths = [
'project',
'task-type'
];
/** * @var array */protected$allowedSortParameters = [
'created_at',
'updated_at',
'name',
'slug'
];
/** * @var array */protected$allowedFilteringParameters = [
'id',
'name',
'slug'
];
/** * Get the validation rules for the resource attributes. * * @param Task $record * the record being updated, or null if it is a create request. * @return array */protectedfunctionattributeRules($record = null)
{
return [
'name' => ['required', 'string', 'between:3,96'],
];
}
/** * Define the validation rules for the resource relationships. * * @param RelationshipsValidatorInterface $relationships * @param object|null $record * the record being updated, or null if it is a create request. * @return void */protectedfunctionrelationshipRules(RelationshipsValidatorInterface$relationships, $record = null)
{
$relationships->hasOne('project', 'projects', is_null($record), false);
$relationships->hasOne('task-type', 'task-types', is_null($record), false);
}
}
<?phpnamespaceApp\JsonApi\Tasks;
useApp\JsonApi\TemplateAuthorizer;
useApp\Models\Project\Project;
useApp\Models\Task\Task;
useCloudCreativity\JsonApi\Contracts\Object\ResourceInterface;
useGate;
useNeomerx\JsonApi\Contracts\Encoder\Parameters\EncodingParametersInterface;
classAuthorizerextendsTemplateAuthorizer
{
/** * Return the Eloquent model to be used for policy checks * * @return string */protectedfunctiongetPolicyModel()
{
returnTask::class;
}
/** * Can the client read many resources at once? * * Encoding parameters are provided in case the parameters such as * filtering or inclusion paths affect whether the resources can be read. * * @param string $resourceType * the requested resource type. * @param EncodingParametersInterface $parameters * the parameters provided by the client * @return bool */publicfunctioncanReadMany($resourceType, EncodingParametersInterface$parameters)
{
returnfalse;
}
/** * Can the client create the provided resource? * * @param string $resourceType * the resource type being created. * @param ResourceInterface $resource * the resource provided by the client. * @param EncodingParametersInterface $parameters * the parameters provided by the client * @return bool */publicfunctioncanCreate($resourceType, ResourceInterface$resource, EncodingParametersInterface$parameters)
{
if (!$resource->getRelationships()->has('project')) {
returnfalse;
}
$projectId = $resource->getRelationships()->getRelationship('project')->getData()->getId();
$project = Project::find($projectId);
returnGate::allows('update', $project);
}
}
Example of bad JSON package which cases server-side error:
I THINK, per this experience, that the validation test relationshipRules() is run AFTER the authorizer is run. That might be okay, it just means that the authorizer logic has to assume that required attributes or relationships might not be present or may be set to null (meaning 'no relationship'). This seems undesirable, but maybe it's important, in which case this should be well documented.
Example below, where setting the relationship "project" to null causes a fatal error "Call to a member function getId() on null in /home/vagrant/Code/hoistway-cms/app/JsonApi/Tasks/Authorizer.php:59". I can design around this by checking first, or it would be fixed if validation were performed first. Maybe there is a reason to not do that, though? Note that 'TemplateAuthorizer' is my own common auth check class, and for Tasks it has a special case so I am only overwriting the relevant test.
Example of bad JSON package which cases server-side error:
The text was updated successfully, but these errors were encountered: