La sécurité

GG_WEB_SOCKET_SECURITY_CHECK s'exécute avant toute utilisation des données envoyées. Ce n'est pas un filtre que le client peut contourner, et la plupart des problèmes du type « ma valeur n'arrive jamais » viennent en réalité de cette méthode qui fait son travail.

Elle vérifie huit choses : le domaine, les droits d'accès selon le type de page, l'authentification de l'utilisateur, les redirections, la publication de la page, la présence de l'événement déclenché sur la page servie, les contraintes du formulaire (obligatoire, type, expression régulière, captcha), et enfin elle retire du POST les données qui n'étaient pas attendues.

La règle qui rend l'ensemble sûr

Un client ne peut déclencher qu'un événement qui existe sur la page qui lui a été servie. Le contrôle relit côté serveur les blocs de la page et y cherche l'événement. Rien dans la requête n'est cru sur parole : ni le nom de la classe, ni le nom de la fonction.

Conséquences que vous rencontrerez en pratique :

• Un call4DFunction choisi librement depuis le client est refusé. Pour appeler une fonction quelconque, posez l'événement sur un bloc relais qui le porte légitimement.
• Les écrans d'administration rendus depuis un gabarit enregistré sont un cas particulier, et étroit : un seul gabarit est accepté, et seulement pour un utilisateur autorisé à modifier la page. Sans cette restriction, n'importe quel visiteur pourrait déclencher les événements d'un écran d'administration depuis une page publique.

La liste blanche qui supprime vos champs en silence

Le contrôle construit $vo_InputsExpected à partir des blocs réellement concernés, puis retire de $vo_POST.vt_FieldValue toute clé qui n'y figure pas.

Les clés attendues sont les noms de champs, les noms de blocs et, pour une listbox, les clés dérivées : _selectedRows, _selectedDatas, _listboxUuidKey, _searchFields, _checkAll.

Un champ que le contrôle ne reconnaît pas disparaît donc sans message. Deux façons d'en arriver là :

• le champ n'a pas de vt_FieldName : il n'est pas dans la liste blanche, il est retiré ;
• le champ est hors du conteneur désigné par vt_SendAllObjectsOfBlocName : il n'a jamais été collecté.

Le symptôme est identique dans les deux cas : la fonction s'exécute, annonce un succès, et n'enregistre rien. Lisez le corps de la requête /bweb/call-action dans l'onglet réseau : si la clé en est absente, le client ne l'a jamais envoyée ; si elle est présente dans la requête mais vide dans 4D, le contrôle l'a retirée.

Codes d'erreur

Sur /bweb/call-action, un refus répond en JSON avec le code, et non par la page d'erreur HTML. Un toast nomme la page et la fonction, parce qu'un refus silencieux coûtait des heures.

Les contraintes sont toujours vérifiées côté serveur

vb_Required, le type de saisie et vt_PregMatch sont validés ici, avant l'exécution de vos hooks. Un contrôle de format écrit dans un hook 4D n'est donc jamais atteint quand la valeur échoue déjà à la contrainte du schéma : la requête est refusée avant.

Notez aussi qu'un type de saisie « non vide » rend la valeur vide invalide. C'est le comportement voulu, mais il surprend quand un champ est légitimement facultatif.

Le captcha

La réponse au captcha est vérifiée côté serveur, en la comparant à celle conservée dans la session. Ne comptez pas pour autant sur le captcha seul pour protéger un formulaire : considérez-le comme un ralentisseur contre les robots naïfs, pas comme un contrôle.

Voir la page Captcha pour la façon dont le défi est généré et consommé.

Voir aussi

• Les événements et le POST : comment l'événement atteint une fonction une fois le contrôle passé
• L'API Claude : /_claude/* a sa propre chaîne d'autorisation, distincte ; ne l'exposez pas sur Internet