Dans la partie introductive de cette série, nous avons eu un bref aperçu de l’architecture REST et de la manière dont elle peut nous aider à créer de meilleures applications. Nous avons ensuite exploré l’histoire des API REST dans WordPress et nous nous sommes présentés à la dernière nouveauté: le plugin API WP REST. Nous avons configuré un environnement de travail de base pour les tests avec le plug-in, qui comprenait l'installation du plug-in et un client HTTP pour l'envoi de demandes ou l'affichage de la réponse du serveur..
Dans la partie actuelle de la série, nous allons configurer un protocole d'authentification de base sur le serveur pour envoyer des requêtes authentifiées afin d'effectuer diverses tâches via l'API REST..
Pour être précis, dans cette partie nous allons:
examiner les différentes méthodes d'authentification disponibles lors de l'utilisation du plug-in API REST
configurer l'authentification de base sur le serveur
envoyer une requête authentifiée à l'aide de Postman
envoyer une requête authentifiée à l'aide de la structure JavaScript
envoyer une requête authentifiée en ligne de commande
envoyer une requête authentifiée à l'aide de l'API HTTP WP
Mais regardons d'abord l'authentification elle-même.
Qu'est-ce que l'authentification??
Dans sa définition la plus élémentaire, l’authentification est le processus de détermination de l’identité d’une personne..
Selon Webopedia:
Processus d'identification d'une personne, généralement basé sur un nom d'utilisateur et un mot de passe. Dans les systèmes de sécurité, l’authentification est distincte de l’autorisation, qui consiste à donner aux individus l’accès aux objets système en fonction de leur identité. L'authentification garantit simplement que la personne est ce qu'elle prétend être, mais ne dit rien sur les droits d'accès de la personne..
Lorsqu'il parle de l'API WP REST, un utilisateur disposant de privilèges suffisants peut effectuer diverses tâches CRUD, telles que créer une publication, récupérer tous les utilisateurs du site ou révoquer les droits d'un utilisateur. Mais pour toutes ces actions, il faut prouver son identité au serveur, et c’est là que l’authentification joue son rôle..
Sans une authentification appropriée, il serait très facile pour une personne ayant des ambitions malveillantes de jouer avec le site. L'authentification fournit donc une couche de sécurité nécessaire pour limiter les droits d'un utilisateur et les actions pouvant être effectuées..
Authentification avec l'API WP REST
L'API REST WP fournit trois options d'authentification, chacune destinée à un usage spécifique. Ces options sont:
authentification de base
Authentification OAuth
authentification par cookie
À l'heure actuelle, l'authentification par cookies est la méthode d'authentification native avec WordPress. C’est ainsi que WordPress détermine l’identité d’un utilisateur et les actions qu’il peut effectuer. Pour utiliser les deux autres méthodes d'authentification répertoriées ci-dessus avec l'API WP REST, vous devez installer leurs plug-ins respectifs fournis par l'équipe API WP REST disponible sur GitHub. Espérons que ces deux méthodes seront également incluses dans le noyau WordPress avec le plugin API REST lui-même..
L'authentification de base est le type d'authentification HTTP le plus fondamental, dans lequel les informations d'identification de connexion sont envoyées avec les en-têtes de la demande..
Comment fonctionne l'authentification de base
Dans l'authentification de base, le client demande une URL nécessitant une authentification. Le serveur demande au client (ou agent d’utilisateur) de s’authentifier en envoyant un message. 401-non autorisé code. En retour, le client renvoie la même demande mais avec les informations d'identification de connexion sous la forme d'une chaîne codée en base64 au format Identifiant Mot de passe. Cette chaîne est envoyée dans le Autorisation champ d'en-tête comme suit:
Autorisation: Basic base64_encode (nom d'utilisateur: mot de passe)
Donc si le nom d'utilisateur est tutsplus et le mot de passe est 123456, le champ d'en-tête suivant serait envoyé avec la demande:
Autorisation: base dHV0c3BsdXM6MTIzNDU2
Étant donné que la chaîne encodée en base64 peut facilement être décodée, cette méthode n’est pas très sûre d’être utilisée sur un réseau ouvert. Par conséquent, cette méthode ne doit être utilisée qu'à des fins de débogage et de développement lorsque la connexion entre le serveur et le client est sécurisée..
Installer le plugin
Comme mentionné ci-dessus, le plug-in est disponible sur GitHub à partir de l'équipe API WP REST. Il suffit donc de le cloner dans notre plugins répertoire et l'activer.
Dirigez-vous vers votre / wp-content / plugins / répertoire et cloner le plugin pour lequel vous pourriez avoir besoin sudo les droits pour exécuter la commande. Pour ce faire, procédez comme suit:
Le terminal vous demandera votre mot de passe. Entrez votre mot de passe et laissez le référentiel être cloné dans un répertoire..
Après avoir cloné le plug-in, activez-le en accédant à votre administrateur WP. La méthode d'authentification HTTP de base peut maintenant être utilisée avec le plugin API REST.
Envoi de demandes authentifiées à l'aide de Postman
La plupart des clients HTTP prennent en charge l'envoi d'une requête en utilisant la méthode d'authentification de base de manière native, de même que Postman pour Chrome. Pour envoyer une requête authentifiée, allez à la Autorisation onglet sous la barre d'adresse:
Maintenant, sélectionnez Authentification de base dans le menu déroulant. Vous serez invité à entrer votre nom d'utilisateur et votre mot de passe. Après avoir entré vos identifiants, cliquez sur le bouton Demande de mise à jour bouton.
Après la mise à jour de l’option d’authentification, vous constaterez une modification de la En-têtes onglet, et il comprend désormais un champ d’en-tête contenant le nom d’utilisateur codé et la chaîne de mot de passe:
C’est la manière dont nous avons configuré l’authentification de base avec Postman. Vous pouvez maintenant envoyer une demande de test comme supprimer un message, ce qui nécessite une authentification:
Où dev-server est le chemin de votre serveur de développement.
Si tout se passe bien, le serveur retournera un 200 OK code de statut, indiquant que la poste avec un identifiant de 52 a été supprimé:
Ne vous inquiétez pas de la demande que nous avons faite ici, nous l'examinerons plus en détail dans les prochaines parties de la série..
Envoi de demandes authentifiées à partir de la ligne de commande
Nous pouvons utiliser la ligne de commande pour envoyer des requêtes authentifiées en utilisant cette méthode. Considérer ce qui suit boucle équivalent de la demande ci-dessus:
curl --request DELETE - I --user admin: mot de passe http: // serveurdev / wp-json / wp / v2 / posts / 52
La réponse suivante serait envoyée par le serveur, indiquant que tout va bien:
HTTP / 1.1 200 OK Date: ven, 28 août 2015 20:02:43 Serveur GMT: Apache / 2.4.6 (CentOS) PHP / 5.6.12 X-Powered-By: PHP / 5.6.12 Set-Cookie: PHPSESSID = k0rg6mcbsie7ufvoav219lqre0; path = / Expires: jeu., 19 nov. 1981 08:52:00 GMT Cache-Control: aucune mémoire, pas de mémoire cache, doit être revalidée, post-vérification = 0, vérification préalable = 0 Note: pas de cache X- Content-Type-Options: nosniff Lien: ; rel = "substitut"; type = text / html Autoriser: GET, POST, PUT, PATCH, DELETE Transfert-codage: chunked Content-Type: application / json; jeu de caractères = UTF-8
le --demande option spécifie la méthode de requête à utiliser, qui dans notre cas est EFFACER. Vous pouvez aussi utiliser -X comme remplaçant du --demande option.
le -je Cette option récupère uniquement les en-têtes HTTP envoyés par le serveur. L'alternative à -je est le --tête option.
Envoi de demandes authentifiées à l'aide de JavaScript
Si vous utilisez un framework JavaScript côté client, tel que jQuery, pour interagir à distance avec un site WordPress dans lequel l'API WP est activée, vous pouvez envoyer les en-têtes d'autorisation dans une demande AJAX. Considérer ce qui suit EFFACER demande envoyée par la jQuery.ajax () méthode:
Où Base64 est un objet utilisé pour encoder et décoder une chaîne base64. Il est défini comme suit, avant ce qui précède jQuery.ajax () appel de méthode:
var Base64 = _ keyStr: "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstwwyz0123456789 + / =", coder: fonction (e) var; tandis que (f> 2; o = (n & 3)<<4|r>> 4; u = (r & 15)<<2|i>> 6; a = i&63;if (isNaN (r)) u = a = 64 sinon if (isNaN (i)) a = 64 t = t + ceci._keyStr.charAt (s) + ceci._keyStr.charAt (o) + ceci ._keyStr.charAt (u) + this._keyStr.charAt (a) renvoyer t, décoder: fonction (e) var; var n, r, i; var s, o, u, a; var f = 0 ; e = e.replace (/ [^ A-Za-z0-9 \ + \ / \ =] / g, ""); tandis que (f> 4; r = (o & 15)<<4|u>> 2; i = (u & 3)<<6|a;t=t+String.fromCharCode(n);if(u!=64)t=t+String.fromCharCode(r)if(a!=64)t=t+String.fromCharCode(i)t=Base64._utf8_decode(t);return t,_utf8_encode:function(e)e=e.replace(/\r\n/g,"\n");var;for(var n=0;n127 && r<2048)t+=String.fromCharCode(r>> 6 | 192); t + = String.fromCharCode (r & 63 | 128) sinon t + = String.fromCharCode (r >> 12 | 224); t + = String.fromCharCode (r >> 6 & 63 | 128); t + = String .fromCharCode (r & 63 | 128) retourne t, _ utf8_decode: fonction (e) var; var n = 0; var r = c1 = c2 = 0; tant que (n191 && r<224)c2=e.charCodeAt(n+1);t+=String.fromCharCode((r&31)<<6|c2&63);n+=2elsec2=e.charCodeAt(n+1);c3=e.charCodeAt(n+2);t+=String.fromCharCode((r&15)<<12|(c2&63)<<6|c3&63);n+=3return t;
Je l’ai trouvé sur StackOverflow, et c’est un moyen de coder et de décoder une chaîne base64 en JavaScript avec plusieurs navigateurs..
Dans la requête ci-dessus, nous définissons la Autorisation en-tête en utilisant le setRequestHeader () méthode du xhr objet passé en argument à la beforeSend () méthode.
Outre la demande ci-dessus, le En-têtes de contrôle d'accès autorisés les en-têtes doivent permettre la Autorisation champ sur le serveur. Cela peut être activé en ajoutant la ligne de code suivante dans votre fichier .htaccess WordPress:
En-tête toujours défini Access-Control-Allow-Headers Authorization Header toujours défini
Une fois terminée, la demande ci-dessus fera écho à la réponse dans la console de votre navigateur, comme indiqué dans la figure ci-dessous:
le 200 code de réponse d'état renvoyé par le serveur indique que la publication avec un identifiant de 52 a été supprimé avec succès.
Envoi de demandes authentifiées à l'aide de l'API HTTP WP
Si vous interagissez à distance avec un autre site WordPress depuis votre installation WordPress, le moyen le plus approprié d'envoyer des demandes HTTP est l'API WP HTTP..
Considérons le code suivant qui envoie un EFFACER demande à une autre installation WordPress avec l'API WP REST et l'authentification de base activée:
Ici nous avons utilisé le wp_remote_request () fonction qui accepte deux arguments:
$ url: l'URL de la requête
$ args: un tableau d'arguments supplémentaires à passer
le méthode $ défini dans le $ args tableau est EFFACER, et il devrait toujours être écrit en majuscule. le $ en-têtes array prend des paires clé-valeur de tous les champs d'en-tête à transmettre avec la requête. Nous avons passé le Autorisation clé avec un nom d'utilisateur et un mot de passe codés en base64 comme valeur.
La réponse serait sauvegardée dans le $ wp_delete_post_response variable, que nous pouvons utiliser avec le wp_remote_retrieve_response_code () et wp_remote_retrieve_response_message () les fonctions. Ces deux fonctions sont des fonctions d'assistance dans l'API HTTP WP et extraient respectivement le code d'état et le message d'état de la réponse..
Si le message est supprimé avec succès par la requête ci-dessus, le texte suivant sera répercuté:
200 OK
Tout cela concerne la méthode d'authentification de base prise en charge par l'API WP REST. Nous utiliserons la même méthode d'authentification dans nos futures pièces pour récupérer, créer ou modifier des données en raison de sa simplicité, sauf indication contraire.
Conclusion
Dans la partie actuelle de la série, nous avons examiné de près la méthode d'authentification HTTP de base prise en charge par l'API WP REST. Cependant, il ne devrait pas être utilisé dans des environnements de production réels, car la chaîne encodée en base64 pourrait facilement être décodée et vos informations d'identification pourraient tomber entre de mauvaises mains..
Après avoir configuré et testé avec succès la méthode d'authentification de base HTTP, nous sommes prêts à aller plus loin et à mettre en place une méthode d'authentification plus sophistiquée, la méthode OAuth 1.0a. Nous ferons cela dans la toute prochaine partie de la série, alors restez à l'écoute!
Share
Accentsconagua
