Contrôle d'accès aux formulaires

Un formulaire est une route publique par défaut. C'est le bon comportement pour un formulaire de contact, et le mauvais pour une note de frais interne, un bon de commande réservé aux partenaires ou une enquête réservée aux membres — dans chacun de ces cas, l'URL doit répondre différemment selon qui la demande.

access énonce l'exigence, avec le même modèle de permissions que les tables, les pages, les buckets, les automatisations et les agents :

forms:
  - id: 2
    name: member-survey
    title: Member Survey
    submitTo: { table: survey_responses }
    access:
      require: authenticated
    fields:
      - { kind: standalone, name: rating, inputType: rating, required: true }

Propriétés d'accès

Propriété	Description	Défaut
require	all, authenticated, ou un tableau de noms de rôles — au moins un élément si c'est un tableau.	all lorsque access est omis.
redirectTo	Chemin vers lequel envoyer un contributeur refusé, à la place de la réponse de refus. Doit commencer par /.	Aucune redirection.

Un tableau de rôles peut aussi désigner un groupe, avec le préfixe group: — ['admin', 'group:partners'] admet quiconque a le rôle admin ou appartient au groupe partners.

redirectTo est accepté et validé aujourd'hui ; la route canonique /forms/{name} répond pour l'instant à un refus par la réponse décrite ci-dessous plutôt que par une redirection.

Ce que reçoit un contributeur refusé

Le contrôle s'applique aussi bien à l'ouverture du formulaire qu'à l'envoi. Le refus n'est délibérément pas uniforme.

require	Visiteur anonyme	Connecté, mauvais rôle	Connecté, bon rôle
omis / all	Autorisé	Autorisé	Autorisé
authenticated	401 — connexion requise	Autorisé	Autorisé
['partner']	404	404	Autorisé

Le 401 nomme le formulaire et le niveau exigé, parce que « connectez-vous pour utiliser ceci » est une information utile à donner au visiteur.

Accès et références $user

Exiger l'authentification est ce qui rend la session disponible au moteur de rendu, et donc ce qui rend $user.<prop> résolvable. Sur un formulaire public il n'y a aucune session à lire : un $user.email placé dans la table prefill est silencieusement abandonné et le champ s'affiche vide.

La forme en ligne de la même référence est plus stricte. Un defaultValue: $user.email par champ sur un formulaire public est rejeté au décodage de la configuration, avec un message nommant le formulaire et le champ — une valeur qui ne pourra jamais que se résoudre à vide est une erreur à intercepter avant le démarrage plutôt qu'une saisie vide à livrer.

Formulaires intégrés

Un formulaire affiché dans une page via formRef conserve son propre contrôle, et la page hérite de la réponse la plus stricte : si un seul formulaire intégré refuse la session, la page entière renvoie 404. L'alternative — afficher la page avec un trou à la place du formulaire — divulguerait l'existence du formulaire par la forme de la page, précisément ce que la restriction par rôle vise à empêcher.

Qui a soumis

Lorsqu'une session est présente, le registre de soumissions enregistre le submitter_user_id à côté des réponses, et la colonne « créé par » d'une table liée reçoit le même identifiant. Les soumissions publiques laissent les deux à null. Le contrôle d'accès est donc aussi ce qui rend une soumission attribuable.

Pages associées

• Rôles et RBAC — les noms de rôles auxquels require se compare.
• Groupes d'authentification — les groupes désignés par une entrée group:.
• Préremplissage — les références $user, qui dépendent de ce contrôle.
• Disponibilité — l'autre raison pour laquelle un formulaire peut refuser une soumission.