Pourquoi devriez-vous supprimer en utilisant un HTTP POST ou SUPPRIMER, plutôt que de les OBTENIR?

J'ai travaillé par le biais de Microsoft ASP.NET MVC tutoriels, se terminant à cette page

http://www.asp.net/learn/mvc/tutorial-32-cs.aspx

L'instruction suivante est effectuée vers le bas de cette page:

En général, vous ne voulez pas effectuer une opération HTTP GET lors de l'appel d'une action qui modifie l'état de votre application web. Lors de l'exécution d'une suppression, vous souhaitez effectuer un HTTP POST, ou mieux encore, un HTTP opération de SUPPRESSION.

Est-ce vrai? Quelqu'un peut-il offrir une explication plus détaillée de la justification de cette affirmation?

Modifier

Wikipédia les états suivants:

Certaines méthodes (par exemple, de la TÊTE, d'OBTENIR, d'OPTIONS et de TRACE) sont définies comme "sûrs", ce qui signifie qu'ils sont destinés uniquement pour la recherche d'information et ne devraient pas changer l'état du serveur.

En revanche, les méthodes telles que POST, PUT et DELETE sont destinés à des actions qui peuvent causer des effets secondaires sur le serveur

InformationsquelleAutor Richard Everett | 2009-04-24

52

Jon Skeet réponse est la réponse canonique. Mais: Supposons que vous avez un lien:
```
href = "\myApp\DeleteImportantData.aspx?UserID=27"
```
et le google-bot vient le long et les index de votre page? Ce qui arrive ensuite?
- Ceci est appelé un " Cross-Site Request Forgery de la vulnérabilité.
- Pas nécessairement. Jetez un oeil sur le lien Marc Gravel posté (L'Araignée de Doom). J'ai lu plusieurs articles qui décrivent exactement ce type de problème, généralement derrière une validation javascript, qui les araignées ignorer. Oui, il pourrait être malveillant, mais la plupart du temps c'est juste de la bêtise.
- Les araignées ne sont pas le problème, l'authentification s'en occupe. De façon plus réaliste question est la <img src="DeleteImportantData.aspx?UserID=27"> choses.
InformationsquelleAutor Chris Cudmore
46

OBTENIR est conventionnelle-gratuite de des effets secondaires- en d'autres termes, il ne modifie pas l'état. Cela signifie que les résultats peuvent être mis en cache, les signets peuvent être effectués en toute sécurité, etc.

De le HTTP 1.1 RFC 2616

Réalisateurs doivent être conscients que l'
logiciel représente l'utilisateur dans leur
les interactions sur l'Internet, et
devez être prudent afin de permettre à l'utilisateur de
être au courant des mesures qu'ils pourraient
prendre ce qui peut avoir un imprévu
signification pour eux-mêmes ou d'autres.

En particulier, la convention a été
établi que le GET et HEAD
les méthodes ne DOIVENT PAS avoir le
l'importance de prendre une autre action
de récupération. Ces méthodes devraient
être considérée comme "sûre". Cela permet à l'utilisateur
les agents de représenter d'autres méthodes,
comme le POST, PUT et DELETE, dans un
de façon particulière, de sorte que l'utilisateur soit
conscient du fait que, éventuellement, un
dangereux d'action est demandée.

Naturellement, il n'est pas possible de
s'assurer que le serveur n'a pas
générer des effets secondaires comme un résultat de
l'exécution d'une requête GET; en fait,
dynamique des ressources considérer qu'un
fonctionnalité. La distinction importante
ici, c'est que l'utilisateur n'a pas demandé
les effets secondaires, donc il ne peut pas
en être tenus responsables.
- Ma compréhension est que la quantité d'actions peuvent changer d'état, mais plusieurs applications d'un idempotent action avoir le même résultat que d'une seule application. Par exemple, HTTP DELETE est la quantité, mais HTTP POST ne l'est pas. GET et HEAD ont le supplémentaire convention (en plus d'idempotence) de ne pas produire d'effets secondaires même sur la demande initiale. Voir stephenwalther.com/archive/2009/01/21/...
- Oui, vous avez raison. Modifier.
InformationsquelleAutor Jon Skeet
17

En dehors de puriste questions autour de l'être idempotent, il y a un côté pratique: les araignées/robots/robots, etc. suivre les liens hypertexte. Si vous avez votre "supprimer" action comme un lien hypertexte qui est un GET, alors google peut gaiement supprimer toutes vos données. Voir "L'Araignée de Doom".

Avec des billets, ce n'est pas un risque.
- L'araignée de doom. c'est drôle...
- Que c'était un super lien!
InformationsquelleAutor Marc Gravell
14

Un autre exemple..
```
http://example.com/admin/articles/delete/2
```
Cela permettra de supprimer cet article, si vous êtes connecté et que vous avez le droit à des privilèges. Si votre site accepte les commentaires, par exemple, et un utilisateur envoie ce lien comme une image; de la sorte:
```
<img src="http://example.com/admin/articles/delete/2" alt="This will delete your article."/>
```
Puis quand vous vous en tant qu'utilisateur administrateur viens de parcourir les commentaires sur votre site, le navigateur va essayer de récupérer cette image par l'envoi d'une demande à cette URL. Mais parce que vous êtes connecté, alors que le navigateur est cela, l'article sera alors supprimé.

Vous ne pouvez pas le même avis, sans regarder le code source comme la plupart des navigateurs l'habitude de montrer quoi que ce soit s'il ne peut pas trouver une image.

L'espoir qui fait sens.
- Super réponse! De navigation en tant qu'admin est une bonne façon de penser.
- Très explication claire. Merci
InformationsquelleAutor Neil
12

Veuillez voir ma réponse ici. Il s'applique également à cette question.
- Prefetch: beaucoup de navigateurs web va utiliser cette fonctionnalité. Ce qui signifie
  qu'il se charge d'une page avant de vous
  cliquez sur le lien. En anticipant qu'
  vous cliquez sur le lien plus tard.
- Les robots: Il y a plusieurs robots qui scannent et l'indice de l'internet pour
  de l'information. Ils n'OBTIENNENT
  les demandes. Vous ne voulez pas supprimer
  quelque chose à partir d'une requête GET pour ce
  raison.
- La mise en cache: OBTENIR les requêtes HTTP ne sont pas censés changer d'état et ils devraient être idempotent. Idempotent signifie que
  l'émission d'une requête une fois, ou de le délivrer
  plusieurs fois donne le même résultat.
  I. e. il n'y a pas d'effets secondaires. Pour
  cette raison, OBTENIR les requêtes HTTP sont
  étroitement lié à la mise en cache.
- HTTP standard dit: HTTP standard dit ce que chaque méthode HTTP est
  pour. Plusieurs programmes sont construits à
  l'utilisation du protocole HTTP, et ils assument
  qui vous permettra de l'utiliser de la façon dont vous êtes
  censé. Ainsi, vous aurez
  un comportement indéfini à partir d'un tas de
  aléatoire des programmes si vous ne suivez pas.
InformationsquelleAutor Brian R. Bondy
4

En plus les araignées et les demandes idempotent il y a aussi un problème de sécurité avec les requêtes get. Quelqu'un peut facilement envoyer à vos utilisateurs un e-mail avec
```
<img src="http://yoursite/Delete/Me" />
```
dans le texte et le navigateur seront heureux de vous aller et d'essayer d'accéder à la ressource. À l'aide de POST n'est pas un remède pour de telles choses (que vous pouvez mettre ensemble un post de formulaire en javascript assez facilement), mais c'est un bon début.

InformationsquelleAutor John Foster
3

Sur ce sujet (HTTP méthodes d'utilisation), je recommande la lecture de ce billet de blog: http://blog.codevader.com/2008/11/02/why-learning-http-does-matter/

C'est en fait le problème inverse: pourquoi ne pas utiliser POST lorsque aucune donnée n'est changé.
- Lien brisé dans un lien seule réponse 🙁
InformationsquelleAutor razenha
2

Disons que nous avons un services bancaires par internet et nous visitez la page de transfert. L'utilisateur choisit de transfert de 10 $à un autre compte.

Cliquant sur le bouton soumettre des redirections (comme une demande GET) pour https://my.bank.com/users/transfer?amount=10&destination=23lk3j2kj31lk2j3k2j

Mais la connexion internet est lente et/ou les serveur(s) est(sont) bien remplie donc, après avoir cliquer sur le bouton soumettre la nouvelle page est en cours de chargement lent.

L'utilisateur est frustré et commence à frapper la touche F5 (actualiser la page) furieusement. Devinez ce qui va arriver? Plus d'un transfert se fera éventuellement vider le compte de l'utilisateur.

Maintenant, si la demande en est faite, comme la POSTE (ou autre chose que GET) la première F5 (actualiser la page) que l'utilisateur fera le navigateur va doucement de demander "êtes-vous sûr de vouloir faire ça? Il peut avoir des effets secondaires [ bla bla bla ] ... "
- Ma Banque ne cette sur son application mobile! C'est de la folie!
- S'il vous plaît dites-moi que c'est une blague.
- Nan pas une blague! Mauvaise pratique est une douleur et m'a coûté plusieurs de frais de découvert.
- c'est vraiment triste 🙁
InformationsquelleAutor Andrei Rînea
2

En dehors de toutes les excellentes raisons mentionnées ici, les requêtes GET pourrait être enregistré par le serveur destinataire, comme dans le access.log. Si vous envoyez à travers des données sensibles comme les mots de passe dans la demande, ils vont se connecté en tant que texte brut.

Même si ils sont hachés/salé pour sécuriser DB de stockage, une violation (ou quelqu'un regarde par-dessus l'informaticien de l'épaule) pourrait révéler. De telles données devraient aller dans le POST corps.

InformationsquelleAutor Siddhartha
1

Une autre question que la commande va à la barre d'adresse du navigateur. Donc, si vous actualisez la page, vous émettez la commande de nouveau, que ce soit "supprimer le dernier truc", "soumettre la commande" ou similaire.
- Ce n'est pas vrai. Le même problème avec la POSTE. Les gens utilisent "POST-REDIRIGER-GET" approche.
- Je ne sais pas pour les autres navigateurs, mais au moins avec Firefox, si j'actualise une page (ou le retour), j'ai atteint après l'envoi d'une requête POST, au moins, il me prévient et me demander si je veux renvoyer la demande. Tandis qu'avec les OBTENIR, vous n'avez aucun avertissement!
InformationsquelleAutor PhiLho

Vous devez vous connecter pour publier un commentaire.