Использование GET вместо POST для удаления данных за аутентифицированными страницами

Question

Я знаю, что вы должны использовать POST всякий раз, когда данные будут изменены на общедоступном веб-сайте. Есть несколько причин, в том числе тот факт, что поисковые системы будут переходить по всем ссылкам и изменять данные.

Мой вопрос: как вы думаете, нормально ли использовать GET за аутентифицированными страницами в чем-то вроде интерфейса администратора?

Одним из примеров будет список продуктов со ссылкой для удаления в каждой строке. Поскольку единственный способ попасть на страницу - это войти в систему, есть ли вред, если просто использовать ссылку с идентификатором продукта в строке запроса?

Разработка для комментариев:

У меня лично нет проблем или трудностей с выполнением удалений с помощью POST. Я только что видел несколько примеров кода в ASP.NET и ASP.NET MVC для страниц, похожих на административные, которые используют GET вместо POST. Мне любопытно мнение людей по этому вопросу.

Answer 1

Соблазн использования GET заключается в том, что вы можете создать кучу ссылок для удаления, не создавая десятки форм на страницу или прибегая к JavaScript.Тем не менее, по различным причинам, которые уже были упомянуты, сеть зависит от того, что GET не являются разрушительными.

Лучше всего, если нецелесообразно создавать одну крошечную форму для каждой ссылки удаления на сервере, это использовать ссылку GET для загрузки страницы подтверждения с сервера , который имеет форму POST.который выполняет удаление.Затем выполните некоторые прогрессивные улучшения:

<a href="/controller/delete/1" onclick="$.post(this.href); return false;">Delete</a>

Если сервер получает GET для / controller / delete / x, тогда откройте страницу подтверждения с формой POST.Если сервер получает запрос POST (или, возможно, DELETE), тогда удалите его.

Answer 2

Некоторое время назад некоторые люди узнали, что это очень плохая идея.

Google запустил новое приложение для «ускорения просмотра» (Google Web Accelerator), которое предварительно выбирало связанные страницы в браузере (без атак, без третьей стороны ...), и когда кто-то заходил на такие защищенные страницы, хорошо Приложение просмотрело все эти ссылки и сказало: «Привет, я предварительно выберу эти ссылки, потому что таким образом у меня есть готовая страница, когда пользователь запрашивает ее»

Они изменили поведение, но любой может сделать что-нибудь подобное в любой день.

Answer 3

GET следует использовать для извлечения данных идемпотентно, а POST следует использовать для безидемпотентного обновления данных. Это все. Конечно, это не «лучшая практика» для обмена методами.

Что касается рисков XSS и CSRF, то для предотвращения одних только HTML-экранирования любого контролируемого пользователем ввода во время (пере) отображения, а для предотвращения другого просто используйте маркеры и / или капчи на основе запросов.

Answer 4

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

Возможно, есть и много других причин ...

Answer 5

Было бы плохой практикой удалять данные на основе запроса GET. Технически, вы можете сделать это, но вы будете не синхронизированы с большинством хорошо написанных сайтов. В основном вы создаете новый набор правил для вашего пользовательского интерфейса, если вы используете GET для удаления. Я считаю URL вашего сайта частью пользовательского интерфейса. Если вы отправите кому-нибудь ссылку типа http://www.fakesite.site/posts/delete?ID=1,, он будет ожидать появления страницы с вопросом, хотят ли они удалить сообщение с идентификатором # 1, а не выполнять фактическое удаление.

Answer 6

Да.

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

Answer 7

Я делаю это на страницах, где я знаю, что кто-то вошел в систему, и я могу проверить право пользователей на удаление чего-либо на основе других данных, которые я храню в своем сеансе. Я бы предложил добавить шаг подтверждения: «Вы уверены, что хотите удалить эту штуку?»

Answer 8

GET и POST очень и очень похожи, за исключением того факта, что GET имеют ограничение по длине действия HTTP, поскольку все они основаны на URL.

Поскольку вы не будете предоставлять доступ людям, которые не прошли аутентификацию, я не считаю, что использование get является проблематичным.