Actualités WEB et WordPress, thèmes, plugins. Ici, nous partageons des conseils et les meilleures solutions de sites Web.

Requêtes à distance avec wp_safe_remote_get

7

Hier, j’ai partagé un post sur la façon d’utiliser wp_remote_getmais j’ai omis une fonction alternative: wp_safe_remote_get. L’objectif initial était d’utiliser le premier message pour montrer :

  1. Ce que la fonction d’origine accepte,
  2. Comment utiliser la fonction d’origine,
  3. Ce que la fonction d’origine renvoie,
  4. À quoi ressemble une mise en œuvre.

Et puis j’allais jeter un oeil à wp_safe_remote_get. Mais il y a un défi: j’ai des amis intelligents. Peu de temps après avoir publié le post, je reçois une réponse de Roy :

Merci Roy! (Assurez-vous de lui dire "Salut !". 🙂

Mais sérieusement, la suite du post d’hier c’est exactement ça: wp_safe_remote_get. Et c’est comment déterminer la différence entre les deux fonctions et quand vous utiliseriez l’une par rapport à l’autre.

wp_safe_remote_get

Directement de la documentation de l’API, nous apprenons :

Cette fonction est idéale lorsque la requête HTTP est adressée à une URL arbitraire. L’URL est validée pour éviter la redirection et les attaques de contrefaçon de demande.

Et similaire à son homologue, il accepte une URL et une série d’arguments qui peuvent spécifier comment la requête est faite.

De plus, tout comme wp_remote_get, il renvoie également un tableau des données de réponse ou une instance de WP_Errorsi la requête échoue.

L’utilisation de cette fonction n’est pas différente de l’utilisation de la précédente, mais elle soulève la question :

Quand utilise-t-on l’un plutôt que l’autre? Plus précisément, quand utilise-t-on wp_remote_getversus wp_safe_remote_get?

Lire la source

Lorsque vous êtes confronté à une situation comme celle-ci, la première meilleure chose à faire est de lire la source :

  1. wp_remote_get
  2. wp_safe_remote_get

Si vous lisez les liens ci-dessus, vous remarquerez que ce dernier rejette les "URL non sécurisées" qui sont déterminées par wp_http_validate_url via une série de vérifications avancées.

Mais encore, lequel dois-je utiliser ?

Cela laisse toujours la question sans réponse, n’est-ce pas? Je pense qu’il est facile de faire la déclaration générale que vous devriez toujours utiliser wp_safe_remote_get (ou wp_safe_remote_post, d’ailleurs).

Cependant, tous les projets sont différents.

Par exemple, si vous travaillez sur un plugin qui ne sera utilisé que sur un intranet et que vous contrôlez, par exemple, une liste blanche d’URL pouvant être transmises à la fonction, vous pouvez utiliser le premier.

Si, toutefois, vous exposez ce dernier aux utilisateurs, utilisez toujours la version sécurisée de la fonction.

Bref

Ma règle d’or est la suivante (et c’est similaire à la désinfection):

Si les utilisateurs vont interagir avec la fonction, assurez-vous qu’ils interagissent avec la version la plus sûre du code possible.

Sinon, il y a trop de risques.

Source d’enregistrement: tommcfarlin.com

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept Read More