Почему вы должны удалять, используя HTTP POST или DELETE, а не GET?
https://stackoverflow.com/questions/786070
-
16-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я работал с помощью руководств Microsoft по MVC ASP.NET, которые заканчиваются на этой странице
http://www.asp.net/learn/mvc/tutorial-32-cs.aspx
Следующее заявление сделано в нижней части этой страницы:
Как правило, вы не хотите выполнять операцию HTTP GET при вызове действия, которое изменяет состояние вашего веб-приложения.При выполнении удаления вы хотите выполнить HTTP POST или, что еще лучше, операцию HTTP DELETE.
Это правда?Может ли кто-нибудь предложить более подробное объяснение обоснования этого заявления?
Редактировать
Википедия заявляет следующее:
Некоторые методы (например, HEAD, GET, OPTIONS и TRACE) определены как безопасные, что означает, что они предназначены только для извлечения информации и не должны изменять состояние сервера.
В отличие от этого, такие методы, как POST, PUT и DELETE, предназначены для действий, которые могут вызвать побочные эффекты либо на сервере
Решение
Ответ Джона Скита является каноническим ответом.Но:Предположим, у вас есть ссылка:
href = "\myApp\DeleteImportantData.aspx?UserID=27"
и бот Google приходит и индексирует вашу страницу?Что произойдет тогда?
Другие советы
GET обычно не имеет побочных эффектов - другими словами, он не изменяет состояние.Это означает, что результаты могут быть кэшированы, закладки могут быть сделаны безопасно и т.д.
Разработчики должны знать, что программное обеспечение представляет пользователя в их взаимодействиях через Интернет, и должны быть осторожны, чтобы позволить пользователю быть в курсе любых действий, которые они могут предпринимайте действия, которые могут иметь неожиданное значение для них самих или других.
В частности, конвенция была установлена, что методы GET и HEAD НЕ ДОЛЖНЫ иметь значения для выполнения действий, отличных от извлечения.Эти методы следует считать "безопасными".Это позволяет агентам пользователя представлять другие методы, такие как POST, ПОМЕСТИТЬ и УДАЛИТЬ, особым образом, чтобы пользователь был осведомлен о том факте, что запрашивается возможно небезопасное действие.
Естественно, невозможно гарантировать, что сервер не будет генерировать побочные эффекты в результате выполнения запроса GET;фактически, некоторые динамические ресурсы считают это особенностью.Важное различие здесь заключается в том, что пользователь не запрашивал побочные эффекты, поэтому не может нести за них ответственность.
Помимо пуристских проблем, связанных с идемпотентностью, есть и практическая сторона:пауки/боты/сканеры и т. д. будут переходить по гиперссылкам.Если у вас есть действие «удалить» в виде гиперссылки, которая выполняет GET, то Google может легко удалить все ваши данные.Видеть "Паук Судьбы".
С постами это не риск.
Другой пример..
http://example.com/admin/articles/delete/2
Статья будет удалена, если вы вошли в систему и обладаете соответствующими привилегиями.Например, если ваш сайт принимает комментарии и пользователь отправляет эту ссылку в виде изображения;вот так:
<img src="http://example.com/admin/articles/delete/2" alt="This will delete your article."/>
Затем, когда вы сами как пользователь-администратор просматриваете комментарии на своем сайте, браузер попытается получить это изображение, отправив запрос на этот URL-адрес.Но поскольку вы вошли в систему, пока браузер делает это, статья будет удалена.
Вы можете даже этого не заметить, не заглядывая в исходный код, поскольку большинство браузеров ничего не отобразят, если не смогут найти изображение.
Надеюсь, это имеет смысл.
Пожалуйста, смотрите мой ответ здесь.Это в равной степени относится и к данному вопросу.
- Предварительная выборка: Многие веб-браузеры будут использовать предварительную выборку.Это означает что он загрузит страницу до того, как вы нажмете на ссылку.Ожидая этого вы нажмете на эту ссылку позже.
- Боты: Существует несколько ботов, которые сканируют и индексируют Интернет в поисках информации.Они будут выдавать только GET Запросы.Вы не хотите удалять что-либо из запроса GET по этой причине.
- Кэширование: Предполагается, что HTTP-запросы GET не изменяют состояние, и они должны быть идемпотентными.Идемпотентный означает, что выдача запроса один раз или выдача его несколько раз дает один и тот же результат.Тоесть.побочных эффектов нет.По этой причине HTTP-запросы GET тесно связаны с кэшированием.
- Так гласит стандарт HTTP:Стандарт HTTP указывает, для чего предназначен каждый HTTP-метод .Несколько программ созданы для использования стандарта HTTP, и они предполагают , что вы будете использовать его так, как вы должны.Таким образом, у вас будет неопределенное поведение от множества случайных программ, если вы не будете следовать.
Помимо того, что пауки и запросы должны быть идемпотентными, существует также проблема безопасности с запросами get.Кто-то может легко отправить вашим пользователям электронное письмо с
<img src="http://yoursite/Delete/Me" />
в тексте, и браузер с радостью попытается получить доступ к ресурсу.Использование POST не является лекарством от таких проблем (поскольку вы можете довольно легко собрать сообщение формы в JavaScript), но это хорошее начало.
По этой теме (использование методов HTTP) я рекомендую прочитать этот пост в блоге: http://blog.codevader.com/2008/11/02/why-learning-http-does-matter/
На самом деле это противоположная проблема:почему бы не использовать POST, если данные не изменяются.
Допустим, у нас есть приложение интернет-банкинга, и мы посещаем страницу перевода.Вошедший в систему пользователь решает перевести 10 долларов США на другой счет.
Нажатие на кнопку отправки перенаправляет (как запрос GET) на https://my.bank.com/users/transfer?amount=10&destination=23lk3j2kj31lk2j3k2j
Но подключение к Интернету медленное и/или сервер(ы) занят(а), поэтому после нажатия кнопки отправки новая страница загружается медленно.
Пользователь расстраивается и начинает яростно нажимать F5 (обновить страницу).Угадайте, что произойдет?Произойдет более одного перевода, возможно, с возможностью опустошения учетной записи пользователя.
Теперь, если запрос сделан как POST (или что-то еще, кроме GET), первая клавиша F5 (обновление страницы), которую пользователь сделает, браузер мягко спросит: «Вы уверены, что хотите это сделать?Могут быть побочные эффекты [бла-бла-бла]…"
Помимо всех веских причин, упомянутых здесь, запросы GET могут регистрироваться сервером-получателем, например, в access.log.Если вы отправляете в запросе конфиденциальные данные, такие как пароли, они будут зарегистрированы в виде открытого текста.
Даже если они хэшированы/солены для безопасного хранения БД, взлом (или кто-то, заглянувший через плечо ИТ-специалиста) может их раскрыть.Такие данные должны находиться в теле POST.
Другая проблема с GET заключается в том, что команда переходит в адресную строку браузера.Поэтому, если вы обновите страницу, вы снова введете команду, будь то «удалить последние данные», «отправить заказ» или что-то подобное.
