{"id":230823,"date":"2022-12-09T11:29:00","date_gmt":"2022-12-09T08:29:00","guid":{"rendered":"https:\/\/wordpress.mediadoma.com\/?p=230823"},"modified":"2022-12-07T11:58:49","modified_gmt":"2022-12-07T08:58:49","slug":"soumission-securisee-du-formulaire-wordpress","status":"publish","type":"post","link":"https:\/\/wordpress.mediadoma.com\/fr\/soumission-securisee-du-formulaire-wordpress\/","title":{"rendered":"Soumission s\u00e9curis\u00e9e du formulaire WordPress"},"content":{"rendered":"\n

Il y a des ann\u00e9es, j’ai \u00e9crit un article dans lequel je partageais une fonction publique pour d\u00e9terminer si l’utilisateur \u00e9tait autoris\u00e9 \u00e0 enregistrer des informations dans la base de donn\u00e9es WordPress. Vous pouvez voir l’essentiel original dans toute sa splendeur (avec les commentaires solides) ici<\/a><\/strong> (il a cinq ans, m\u00eame – wow).<\/p>\n

Comme pour tout ce qui concerne la programmation, le temps passe, les choses s’affinent et les choses [esp\u00e9rons-le] s’am\u00e9liorent par rapport \u00e0 avant.<\/p>\n

Bien que j’utilise et recommande toujours une variante de la fonction user_can_save<\/strong> (ou userCanSave<\/strong> ), je pense \u00e9galement qu’il est important de passer par le processus de s\u00e9paration du processus de v\u00e9rification de la demande.<\/p>\n

Alors maintenant, il ne s’agit pas seulement de d\u00e9terminer si l’utilisateur a des autorisations, mais il s’agit de v\u00e9rifier les informations de s\u00e9curit\u00e9 provenant du client – que ce soit via une publication vers le serveur ou une demande faite via Ajax – et de le faire en utilisant de bonnes techniques de programmation qui s’alignent \u00e0 la fois avec WordPress et avec PHP.<\/p>\n

Pour \u00eatre clair, il s’agit plus d’une soumission de formulaire WordPress s\u00e9curis\u00e9e \u00e0 partir d’une page d’options ou d’une page de param\u00e8tres que d’un formulaire provenant d’un mod\u00e8le. C’est un autre post pour une autre fois.<\/p>\n

Mais encore, nous sommes nombreux \u00e0 travailler sur la cr\u00e9ation d’applications sur WordPress et qui n\u00e9cessitent ce qui suit.<\/p>\n

Soumission s\u00e9curis\u00e9e du formulaire WordPress<\/h2>\n

Dans cet article, je ne vais pas me pr\u00e9occuper de passer en revue les d\u00e9tails pour d\u00e9terminer si quelque chose est une sauvegarde automatique<\/a><\/strong> ou une r\u00e9vision de publication.<\/a><\/strong><\/p>\n<\/p>\n

Cependant, je vais parcourir le processus de prise en charge d’une fonction charg\u00e9e de valider les informations entrantes et de le faire en utilisant une approche moderne utilisant des pratiques orient\u00e9es objet et \u00e0 la fois des API WordPress et des fonctions PHP.<\/p>\n

1 Commencer \u00e0 un niveau g\u00e9n\u00e9rique<\/h3>\n

Du niveau fondamental, supposons qu’il existe une classe de base \u00e0 partir de laquelle il existe d’autres sous-classes qui exploitent cette fonction. Cela nous indique que nous devons utiliser le modificateur de visibilit\u00e9 prot\u00e9g\u00e9.<\/p>\n

Nous savons \u00e9galement que nous allons avoir affaire \u00e0 une valeur WordPress nonce et \u00e0 une action associ\u00e9e. Cela signifie que la signature de la fonction ressemblera \u00e0 ceci<\/a><\/strong>\u00a0:<\/p>\n

<?php\nprotected function verifyRequest($nonce, $action);<\/code><\/pre>\n
2 D\u00e9sinfectez les donn\u00e9es, v\u00e9rifiez le nonce<\/h3>\n
Comme pour tout ce qui est publi\u00e9 sur le serveur, nous savons que nous allons devoir v\u00e9rifier que les donn\u00e9es sont d\u00e9finies et si c’est le cas, nous allons devoir nettoyer les informations.<\/p>\n
Cela signifie que nous allons avoir besoin des fonctions suivantes\u00a0:<\/p>\n