Déconnexion: GET ou POST?

Cette question ne concerne pas quand utiliser GET ou POST en général; il s'agit de celui qui est recommandé pour gérer la déconnexion d'une application Web. J'ai trouvé beaucoup d'informations sur les différences entre GET et POST dans le sens général, mais je n'ai pas trouvé de réponse définitive pour ce scénario particulier.

En tant que pragmatique, je suis enclin à utiliser GET, car sa mise en œuvre est beaucoup plus simple que POST; déposez simplement un lien simple et vous avez terminé. Cela semble être le cas avec la grande majorité des sites Web auxquels je peux penser, au moins du haut de ma tête. Même Stack Overflow gère la déconnexion avec GET.

Ce qui me fait hésiter, c'est l'argument (quoique ancien) selon lequel certains accélérateurs / mandataires Web pré-cachent les pages en allant récupérer tous les liens qu'ils trouvent dans la page, afin que l'utilisateur reçoive une réponse plus rapide lorsqu'il clique dessus. Je ne sais pas si cela s'applique toujours, mais si c'était le cas, alors en théorie, un utilisateur avec l'un de ces accélérateurs serait expulsé de l'application dès qu'elle se connecterait, car son accélérateur trouverait et récupérerait la déconnexion lien même si elle n'a jamais cliqué dessus.

Tout ce que j'ai lu jusqu'à présent suggère que POST devrait être utilisé pour des "actions destructrices", alors que les actions qui ne modifient pas l'état interne de l'interrogation de type application et autres devraient être traitées avec GET . Sur cette base, la vraie question ici est:

La déconnexion d'une application est-elle considérée comme une action destructrice / modifie-t-elle l'état interne de l'application?

Utilisez POST.

En 2010, l'utilisation GETétait probablement une réponse acceptable. Mais aujourd'hui (en 2013), les navigateurs prélèveront les pages qu'ils "pensent" que vous visiterez ensuite.

Voici l'un des développeurs de StackOverflow parlant de ce problème sur Twitter:

Je tiens à remercier ma banque pour avoir déconnecté une demande GET et l'équipe Chrome pour la préchargement pratique des URL.- Nick Craver ( @Nick_Craver ) 29 janvier 2013

fait amusant: StackOverflow était utilisé pour gérer la déconnexion via GET, mais plus maintenant.

Dans REST, il ne devrait pas y avoir de session, il n'y a donc rien à détruire. Un client REST s'authentifie à chaque demande. Connecté ou déconnecté, ce n'est qu'une illusion.

Ce que vous demandez vraiment, c'est si le navigateur continue d'envoyer les informations d'authentification à chaque demande.

Sans doute, si votre application crée l'illusion d'être connecté, vous devriez pouvoir vous "déconnecter" en utilisant javascript. Aucun aller-retour requis.

Dissertation sur le terrain - Section 5.1.3

chaque demande du client au serveur doit contenir toutes les informations nécessaires à la compréhension de la demande et ne peut profiter d'aucun contexte stocké sur le serveur. L'état de la session est donc entièrement conservé sur le client

Une façon GETpourrait être abusée ici est qu'une personne (un concurrent peut-être :) a placé une balise d'image avec src="<your logout link>"N'IMPORTE O, sur Internet, et si un utilisateur de votre site tombe sur cette page, il sera déconnecté sans le savoir.

Pour être correct, GET / POST (ou d'autres verbes) sont des actions sur une ressource (adressée par URL) - donc c'est généralement sur l'état de la ressource et non sur l'état de l'application en tant que tel. Donc, dans les vrais esprits, vous devriez avoir une URL telle que [host name]\[user name]\session, alors 'SUPPRIMER' serait le verbe correct pour l'action de déconnexion.

L'utilisation en [host name]\bla bla\logouttant qu'URL n'est pas vraiment un moyen complet REST (IMO), alors pourquoi débattre de l'utilisation correcte de GET / POST dessus?

Bien sûr, j'utilise également GET pour une URL de déconnexion dans mes applications :-)

La déconnexion n'a aucun effet sur l'application elle-même. Il modifie l'état de l'utilisateur par rapport à l'application. Dans ce cas, il semble que votre question soit davantage basée sur la façon dont la commande doit être lancée par l'utilisateur pour commencer cette action. Comme il ne s'agit pas d'une "action destructrice", bien sûr que la session est abandonnée ou détruite mais que ni votre application ni vos données ne sont modifiées, il n'est pas impossible d'autoriser les deux méthodes à lancer une procédure de déconnexion. La publication doit être utilisée par toutes les actions initiées par l'utilisateur (par exemple - l'utilisateur clique sur "Déconnexion"), tandis que get peut être réservé aux déconnexions initiées par l'application (par exemple - une exception détectant une intrusion potentielle de l'utilisateur redirige de force vers la page de connexion avec une déconnexion GET ).

Bonjour de mon point de vue, lorsque vous vous connectez, vous vérifiez le nom d'utilisateur / mot de passe et si ceux-ci correspondent, vous créez le jeton de connexion.

Jeton CREAT => méthode POST

Lorsque vous vous déconnectez, vous détruisez le jeton, donc pour moi, la méthode la plus logique devrait être un SUPPRIMER

DELETE token => méthode DELETE

Le scénario de pré-mise en cache est intéressant. Mais je suppose que si de nombreux sites ne vous inquiètent pas, vous ne devriez peut-être pas non plus.

Ou peut-être que le lien pourrait être implémenté en javascript?

Edit: Si je comprends bien, techniquement, un GET devrait être pour les demandes en lecture seule, qui ne changent pas l'état de l'application. Un POST doit être destiné aux demandes d'écriture / modification qui changent d'état. Cependant, d'autres problèmes d'application pourraient préférer GET à POST pour certaines demandes de changement d'état, et je ne pense pas qu'il y ait de problème avec cela.

Eh bien, si vous laissez votre application Web abandonner la session via un script de déconnexion, vous n'avez généralement pas besoin non plus. Normalement, il existe une variable de session unique pour la session que vous souhaitez abandonner.

Récemment, je travaillais sur un projet que j'utilise GET to Logout Ci-dessous, le code dans Nodejs Express et il fonctionne parfaitement bien

votre router.js

const express = require("express");
router.get("/signout", signout);

votre controller.js

exports.signout  = (req, res) => {
        res.clearCookie('t'); //clearing cookie, which is 
            //assign to the user during sign in.          
            res.json({message : 'Signout success'});   
        };

Je ne vois pas comment la déconnexion (de-élévation des autorisations utilisateur) est une action destructrice. C'est parce que l'action "déconnexion" ne devrait être disponible que pour les utilisateurs déjà connectés, sinon elle serait obsolète.

Une chaîne générée aléatoirement contenue dans les cookies de votre navigateur représente tous votre session utilisateur. Il existe des tonnes de façons de le détruire si efficacement que la déconnexion n'est qu'un service rendu à votre visiteur.