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 au sens général, mais je n’ai pas trouvé de réponse définitive à 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 vous avez terminé. Cela semble être le cas avec la grande majorité des sites Web auxquels je peux penser, du 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 (bien qu’ancien) selon lequel certains accélérateurs / proxys Web pré-cache les pages en allant et en récupérant chaque lien qu’ils trouvent dans la page, de sorte que l’utilisateur obtienne une réponse plus rapide en cliquant dessus. Je ne sais pas si cela s’applique toujours, mais si tel était le cas, en théorie, un utilisateur avec l’un de ces accélérateurs serait exclu 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’ici suggère que POST devrait être utilisé pour les “actions destructives”, alors que les actions qui ne modifient pas l’état interne de l’application, comme les requêtes, devraient ê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?

Utilisez POST .

En 2010, l’utilisation de GET était probablement une réponse acceptable. Mais aujourd’hui (en 2013), les navigateurs vont pré-extraire les pages qu’ils “pensent” vous rendre prochainement.

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

Je tiens à remercier ma banque pour avoir déconnecté une requête GET, et l’équipe Chrome pour le préchargement d’URL pratique. – Nick Craver ( @Nick_Craver ) 29 janvier 2013

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

Dans REST, il ne devrait y avoir aucune session, donc il n’y a rien à détruire. Un client REST s’authentifie à chaque demande. Connecté ou déconnecté, c’est juste une illusion.

Ce que vous demandez vraiment, c’est si le navigateur continue à envoyer les informations d’authentification sur chaque requête.

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


Mémoire de terrain – Section 5.1.3

Chaque demande du client au serveur doit contenir toutes les informations nécessaires pour comprendre la demande et ne peut tirer parti d’aucun contexte stocké sur le serveur. L’état de la session est donc entièrement conservé sur le client

Une des manières dont GET pourrait être abusé est qu’une personne (un concurrent peut-être 🙂 a placé une balise d’image avec src="" PARTOUT sur Internet, et si un utilisateur de votre site tombe sur cette page, il sera inconsciemment déconnecté.

Pour être correct, GET / POST (ou d’autres verbes) sont des actions sur certaines ressources (adressées par URL) – il s’agit donc généralement de l’état de la ressource et non de l’état de l’application en tant que telle. Donc, dans les vrais esprits, vous devriez avoir une URL telle que [host name]\[user name]\session , puis “SUPPRIMER” serait le verbe correct pour l’action de déconnexion.

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

Bien sûr, j’utilise aussi GET pour une url de déconnexion dans mes applications 🙂

La déconnexion ne fait rien pour l’application elle-même. Il modifie l’état de l’utilisateur par rapport à l’application. Dans ce cas, il semble que votre question repose davantage sur la manière dont la commande doit être lancée par l’utilisateur pour commencer cette action. Étant donné qu’il ne s’agit pas d’une “action destructive”, 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 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»), alors que get peut être réservé aux ouvertures de session initiées par l’application (par exemple, une exception détectant une intrusion potentielle ).

Bonjour de mon sharepoint 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.

CREAT token => méthode POST

Lorsque vous vous déconnectez, vous détruisez le jeton. La méthode la plus logique devrait donc être DELETE.

DELETE token => méthode DELETE

Le scénario de pré-mise en cache est intéressant. Mais je suppose que si beaucoup de sites ne se soucient pas de cela, alors peut-être vous ne devriez 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 requêtes en lecture seule, qui ne modifient pas l’état de l’application. Un POST devrait être pour les demandes d’écriture / modification qui changent d’état. Cependant, d’autres problèmes d’application pourraient préférer GET over POST pour certaines demandes de changement d’état, et je ne pense pas que cela pose problème.

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

Je ne vois pas en quoi la déconnexion (suppression des permissions utilisateur) est une action destructive. C’est parce que l’action “logout” ne devrait être disponible que pour les utilisateurs déjà connectés sinon elle serait obsolète.

Une chaîne générée de manière aléatoire contenue dans les cookies de votre navigateur représente votre session d’utilisateur. Il y a des tas de façons de le détruire si bien que la déconnexion est simplement un service pour votre visiteur.