Déconnexion : GET ou POST ?

Question

Cette question ne porte pas sur le moment où il faut utiliser GET ou POST en général ; il s'agit de savoir quelle est la solution recommandée pour gérer la déconnexion d'une application web. J'ai trouvé beaucoup d'informations sur les différences entre GET et POST au sens général, mais je n'ai pas trouvé de réponse précise 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 ; il suffit de déposer un simple lien et le tour est joué. Cela semble être le cas pour la grande majorité des sites web auxquels je pense, du moins pour ce qui me vient à l'esprit. Même Stack Overflow gère la déconnexion avec GET.

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

Tout ce que j'ai lu jusqu'à présent suggère que POST doit être utilisé pour les "actions destructives", tandis que les actions qui ne modifient pas l'état interne de l'application - comme les requêtes et autres - doivent être traitées avec GET. . Sur cette base, la vraie question est la suivante :

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

Answer 1

Utilisez POST .

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

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

J'aimerais remercier ma banque pour avoir fait de la déconnexion une requête GET, et l'équipe de Chrome pour la préextraction d'URL pratique - Nick Craver ( @Nick_Craver ) 29 janvier 2013

Fait amusant : StackOverflow avait l'habitude de gérer la déconnexion via GET, mais plus maintenant.

Answer 2

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

Ce que vous demandez en réalité, c'est si le navigateur doit continuer à envoyer les informations d'authentification à chaque demande.

Si votre application crée l'illusion d'une connexion, vous devriez être en mesure de vous déconnecter en utilisant le javascript. Aucun aller-retour n'est nécessaire.

---

Dissertation Fielding - 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 pas profiter d'une quelconque contexte stocké sur le serveur. La session est donc entièrement conservé sur le le client

Answer 3

Une façon GET pourrait être abusé ici est qu'une personne (un concurrent peut-être :) a placé une balise 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.

Answer 4

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

Utilisation de [host name]\bla bla\logout comme l'URL n'est pas vraiment un moyen REST complet (IMO), alors pourquoi débattre de l'utilisation correcte de GET/POST sur elle ?

Bien sûr, j'utilise aussi le GET vers une url de déconnexion dans mes applications :-)

Answer 5

La déconnexion n'a aucun effet sur l'application elle-même. Elle modifie l'état de l'utilisateur par rapport à l'application. Dans ce cas, il semble que votre question soit plutôt basée sur la manière dont l'utilisateur doit lancer la commande pour commencer cette action. Puisqu'il ne s'agit pas d'une "action destructive", c'est-à-dire que la session est abandonnée ou détruite mais que ni votre application ni vos données ne sont altérées, il n'est pas infaisable de permettre aux deux méthodes de lancer une procédure de déconnexion. La méthode post devrait être utilisée par toute action initiée par l'utilisateur (par exemple, l'utilisateur clique sur "Log out"), tandis que la méthode get pourrait être réservée 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 un GET de déconnexion).