Рекомендации GET против POST

Ответ 1

В общем случае не рекомендуется иметь запрос GET, который каким-то образом изменяет состояние системы, например удаление элемента.

Возможно, ваша форма будет выглядеть так:

<form action='item.php' method='POST' id='form'>
    <input type='hidden' name='action' value='delete' />
    <input type='hidden' name='id' value='{item_id}' />
    <a href="" onclick="document.getElementById('form').submit(); return false;">Delete item</a>
</form>

Ответ 2

Пожалуйста, используйте POST для всего, что изменяет постоянное состояние в базе данных. Вы не хотите, чтобы сканеры посещали ваши ссылки на удаление! Прочитайте в Архитектура Всемирной паутины, Том 1 и URI, Адресабельность и использование HTTP GET и POST W3C.

Изменить. Иногда вам нужно использовать GET. Например, URL-адреса активации членства, которые отправляются в электронной почте, являются GET и должны каким-то образом изменить базу данных.

Ответ 3

Из запроса GET вы никогда не должны ничего менять в своей базе данных (кроме информации о регистрации или других эфемерных данных). Проблема в том, что существует множество программ для веб-пауков, веб-ускорителей, антивирусных программ и т.п., Которые будут выполнять запрос GET по каждому найденному URL-адресу; вы не захотите, чтобы они автоматически удаляли элементы, когда они это делают. GET также уязвим для подделки запросов на межсайтовый запрос; если злоумышленник заставляет одного из ваших пользователей нажимать на ссылку, которая выполняет плохие действия (например, создавая tinyurl, который перенаправляет URL-адрес удаления), тогда они могут обмануть пользователя в использовании их разрешений, чтобы удалить что-то, не осознавая этого.

Да, вам понадобится форма, которую вы отправляете для создания запроса POST. Другой вариант - использовать JavaScript и XMLHttpRequest, но это не будет работать для пользователей, у которых отключен JavaScript.

Вы также должны убедиться, что после того, как вы приняли данные из запроса POST, вместо того, чтобы возвращать новую страницу в ответ на этот запрос, вы должны перенаправить пользователя на страницу, к которой обращается запрос GET. Таким образом, они не будут случайно перенаправлять запрос POST, если они нажмут перезагрузку, или нажмите кнопку "Назад" позже в своем сеансе просмотра.

Ответ 4

Вы не хотите использовать Get из-за принципа REST, который не позволяет Gets изменять состояние системы. Если вы не хотите, чтобы поисковые системы удаляли весь ваш контент.

Вам не нужна форма для каждого элемента; вы можете использовать один метод = почтовая форма вокруг списка с типом ввода delete_ {id} = submit. Или, более умно, < input type = submit name= "delete_item" value = "{id}" > . Имена разрешены для кнопок отправки.

По вашему вопросу в комментариях < input type = submit name= "action_ {id}" value = "Delete" > может работать лучше, хотя он страдает некоторыми проблемами, которые будут плохо работать для локализованных сайтов. Вы всегда можете вернуться к HTML-кнопке, чтобы немного больше контролировать презентацию. Он действует как кнопка отправки по умолчанию.

Тот факт, что вы можете получить дополнительную, нежелательную информацию в представлении, смягчается средним случаем отправки назад гораздо более крупной страницы, чем это необходимо, с предлагаемым решением для каждого элемента, когда вы просто просматриваете список, Вы всегда можете использовать javascript, чтобы заменить поведение формы plain-old-html более умной версией для клиентов, поддерживающих javascript.

Если вы собираетесь ссылаться на "Get" для удаления, вы должны вернуть страницу подтверждения с помощью Get, которая на самом деле делает сообщение после подтверждения.

Ответ 5

Вот хороший пример того, почему нельзя использовать GET для изменения состояния сервера:

http://www.infoworld.com/article/08/06/16/25FE-stupid-users-part-3-admins_5.html

Ключевая часть:

"Он зарегистрировался в административной области и следил за ссылкой 'delete' для каждая запись", - говорит администратор.

Если удаление было закодировано как POST, это никогда бы не произошло. (OTOH нас бы ограбили из забавной истории сисадмина.)

Ответ 6

POST не является защитой от всех вредоносных действий, как это предполагают некоторые люди. Вредоносные пользователи по-прежнему могут создавать ссылки (содержащие javascript для POST) и вызывать те же проблемы с межсайтовыми сценариями, что и с GET. (< a href= "javascript: function() {...}" / > )

Тем не менее, все другие причины использования POST поверх GET применяются (сканеры и т.п.).

Ответ 7

Как говорили другие, очень сложно использовать GET для деструктивных операций, таких как удаление, особенно на веб-сайтах, ориентированных на Интернет (или корпорации с устройством Google Mini), где веб-сканеры могут случайно удалить все ваши данные.

Если вы не хотите использовать форму, используйте XMLHttpRequest для отправки POST на ваш сервер. Вы даже можете установить метод DELETE, если ваш сервер поддерживает это.

Если вы не можете использовать JavaScript и XHR (ваши пользователи живут в 1999 году), и вы не хотите использовать форму в своем списке, используйте ссылку на отдельную страницу, где вы можете показать форму и, возможно, a 'Вы уверены?' сообщение.

Лучшее, что можно сделать, это, вероятно, комбинация двух вышеперечисленных опций: Проведите ссылку на отдельную страницу с формой, но используйте JavaScript, чтобы переписать ссылку как вызов XHR. Таким образом, пользователи с 1999 или 2009 года могут иметь оптимальный опыт.

Ответ 8

Вы не должны использовать href для удаления элемента.

Я бы предложил сделать это старомодным способом и реализовать форму-пост для каждой строки/элемента.

Например:

<tr><td>Item 1</td><td><form action=/delete method=post><input type=hidden name=id value=1><input type=submit value=Delete></form></tr>
<tr><td>Item 2</td><td><form action=/delete method=post><input type=hidden name=id value=2><input type=submit value=Delete></form></tr>
<tr><td>Item 5</td><td><form action=/delete method=post><input type=hidden name=id value=5><input type=submit value=Delete></form></tr>

Два других варианта: 1), используя один для каждого элемента 2) Ajax (но вам нужно будет владеть Ajax)

Ответ 9

вы также можете использовать get, но вам нужно будет проверить значения сеанса, чтобы убедиться, что он является владельцем сообщения, которое пытается удалить. get не является "универсально опасным". это полностью зависит от того, как вы его используете.

Ответ 10

Его еще лучше сделать с GET.

Если ваша проблема в том, что вам не нравится уродливый URL вашей ссылки, вы можете исправить это с помощью mod_rewrite (если вы используете веб-сервер Apache).

Изменить: Нет никакой причины использовать POST здесь. Нет. Причина.

Люди вокруг здесь пишут о безопасном и небезопасном, как будто метод выбора может каким-либо образом повлиять на безопасность. Конечно, вы должны аутентифицировать своего пользователя независимо от того, какой метод вы выберете. Если вы этого не сделаете, ваше программное обеспечение уже сломано. Если вы используете javascript для эмулирования отправки формы, когда у вас нет формы, и она не нужна, вам вообще не нужен javascript, тогда ваше программное обеспечение уже сломано.

На самом деле, около 90% веб-программного обеспечения нарушено, потому что люди не имеют представления о том, что они делают.

Игнорируйте эти комментарии, которые сильно игнорируются некоторыми странными людьми. Избегайте javascript (нет необходимости), избегайте POST (нет причины), аутентифицируйте своего пользователя (безопасность), делайте href красивым с помощью mod_rewrite или каким-либо другим способом (быть красивым).