Je précise une chose que j’avais totalement zappée.
Dans Laravel, on a un concept qui s’appelle : FormRequest, et qu’on peut définir pour une route.
Si c’est défini, Laravel exécutera dans l’ordre ses méthodes authorize puis rules. authorize (et donc rules) sont exécutées au tout début de l’appel de la route (et donc avant la "vraie" méthode du contrôleur que la route appelle).
Le but est donc de vérifier que l’utilisateur authentifié a les autorisations nécessaires (authorize) (genre par exemple : est-ce que son rôle est bien "applier" pour pouvoir postuler ? Et non pas le rôle "firm" puisqu’une société ne peut pas postuler). Si oui, on vérifie les inputs de la charge utile de la requête du client (rules) (genre si le champ "password" contient bien 13 caractères par exemple). Si oui, alors la "vraie" méthode du contrôleur est exécutée.
Et donc, là où je veux en venir, c’est que : si j’utilise ta solution, @SpaceFox (laquelle est très logique et cohérente, et je l’ai mise en place actuellement) , alors la méthode authorize telle que je peux la définir va forcément reposer sur… la payload de la requête ! Ce qui est un non-sens puisque comme tu l’as certainement compris, la payload est vérifiée dans rules qui s’exécute après authorize : Laravel a dans l’idée de d’abord checker si l’utilisateur a les permissions et ENSUITE checker le contenu de la payload. Le fait de devoir définir authorize en fonction du contenu de la payload est donc une sorte de non-sens.
J’illuse cela :
public function authorize()
{
if(request()->has('job') && request()->has('job.attach_or_detach')) {
if(request()->input('job.attach_or_detach')) {
return $this->user()->can('attach-job');
} else {
$job = Job::findOrFail(request()->input('job.id'));
return $this->user()->can('detach-job', $job);
}
}
return true;
}
-
Comme tu peux le voir : si la payload contient job.attach_or_detach == TRUE (= si l’utilisateur postule), alors je vérifie qu’il est bien un "applier" et non une "firm" par exemple (c’est ce qu’il y a derrière $this->user()->can('attach-job');).
-
Similairement, si ça vaut FALSE (= si l’utilisateur annule sa candidature au job), alors je vérifie qu’il est bien un "applier" et non une "firm" et que le job de la requête fait bien partie des jobs auxquels il a postulés (c’est ce qu’il y a derrière $this->user()->can('detach-job');.
Comme tu peux le voir, authorize se base sur la payload (job.attach_or_detach), alors que Laravel ne vérifiera le bon format etc. de la payload (dans rules) qu’après avoir exécuté authorize :
public function rules()
{
return [
'name' => 'nullable|string',
'job' => 'nullable|array:id,attach_or_detach,message|required_array_keys:id,attach_or_detach',
'job.id' => 'integer|gt:0',
'job.attach_or_detach' => 'boolean',
'job.message' => 'required_if:job.attach_or_detach,true|string',
];
}
:
je rigole