Выход: GET или POST?

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

Как прагматик, я склонен использовать GET, потому что реализация его проще, чем POST; просто оставьте простую ссылку, и все готово. Это похоже на подавляющее большинство веб-сайтов, о которых я могу думать, по крайней мере, с моей головы. Даже Qaru обрабатывает выход из системы с помощью GET.

Вещь, заставляющая меня стесняться, является (хотя и старым) аргументом, что некоторые веб-ускорители/прокси-серверы предварительно кэшируют страницы, перейдя и получая каждую ссылку, которую они находят на странице, поэтому пользователь получает более быстрый ответ, когда она нажимает на них. Я не уверен, что это все еще действует, но если это так, то теоретически пользователь с одним из этих ускорителей выйдет из приложения сразу после входа в систему, потому что ее ускоритель найдет и извлечет выход из системы link, даже если она никогда не нажимала на нее.

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

Выходит из приложения, считающегося деструктивным действием/изменяет внутреннее состояние приложения?

Ответ 1

Используйте POST.

В 2010 году использование GET было, вероятно, приемлемым ответом. Но сегодня (в 2013 году) браузеры будут предварительно набирать страницы, которые они "думают", что вы будете посещать дальше.

Вот один из разработчиков StackOverflow, который говорит об этой проблеме в twitter:

Я хотел бы поблагодарить мой банк за то, что он выходил из GET-запроса, и команда Chrome за удобную предварительную выборку URL. - Nick Craver (@Nick_Craver) 29 января 2013 г.

fun fact: StackOverflow используется для обработки выхода из системы через GET, но не более того.

Ответ 2

В REST не должно быть сеанса, поэтому уничтожить нечего. Клиент REST аутентифицируется по каждому запросу. Записан У этого пользователя есть подпись, которая отображается под каждым сообщением, но вы не можете ее просматривать.

Что вы действительно спрашиваете, должен ли браузер продолжать отправлять данные аутентификации по каждому запросу.

Возможно, если ваше приложение создает иллюзию входа в систему, вы должны иметь возможность "выйти из системы" с помощью javascript. Не требуется поездка туда и обратно.

Филдинг Диссертация - Раздел 5.1.3

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

Ответ 3

Один из способов GET можно злоупотреблять здесь, так это то, что человек (конкурент, возможно,:) помещал тег изображения с помощью src="<your logout link>" ANYWHERE в Интернете, и если пользователь вашего сайта натыкается на эту страницу, он будет неосознанно вышли из.

Ответ 4

Выход из системы ничего не делает для самого приложения. Он изменяет состояние пользователя относительно приложения. В этом случае, похоже, ваш вопрос больше основан на том, как должна инициироваться команда от пользователя для начала этого действия. Поскольку это не является "деструктивным действием", убедитесь, что сеанс оставлен или уничтожен, но ни ваше приложение, ни ваши данные не изменены, не исключено, чтобы оба метода инициировали процедуру выхода из системы. Сообщение должно использоваться любыми инициированными пользователем действиями (например, пользовательские клики "Выход из системы" ), в то время как get может быть зарезервирован для отложенных приложений (например, обнаружение исключений потенциальное вторжение пользователя принудительно перенаправляет на страницу входа в систему с выходом из системы GET).

Ответ 5

Чтобы быть верным, GET/POST (или другие глаголы) являются действиями на каком-либо ресурсе (адресованном по URL-адресу) - так что обычно это касается состояния ресурса, а не состояния приложения как такового. Итак, в истинном духе у вас должен быть URL-адрес, например [host name]\[user name]\session, тогда "DELETE" будет правильным глаголом для выхода из системы.

Используя [host name]\bla bla\logout в качестве URL-адреса, который не является полноценным способом REST (IMO), так зачем обсуждать правильное использование GET/POST на нем?

Конечно, я также использую GET для URL-адреса выхода в моих приложениях: -)

Ответ 6

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

Или, может быть, ссылка может быть реализована в javascript?

Изменить: как я понимаю, технически GET должен быть для запросов только для чтения, которые не меняют состояние приложения. POST должен быть для запросов на запись/редактирование, которые изменяют состояние. Однако другие проблемы с приложениями могут предпочесть GET через POST для некоторых запросов, изменяющих состояние, и я не думаю, что с этим возникли проблемы.

Ответ 7

Здравствуйте, с моей точки зрения, когда вы входите в систему, вы проверяете имя пользователя/пароль, и если они совпадают, вы создаете токен входа.

CREAT token = > метод POST

Когда вы выходите из системы, вы меняете токен, поэтому для меня самым логичным методом должен быть DELETE

DELETE token = > метод DELETE

Ответ 8

Хорошо, если вы позволите своему веб-приложению отказаться от сеанса через выход из системы script, вам, как правило, тоже не нужно. Обычно есть переменная сеанса, которая уникальна для сеанса, который вы хотите оставить.

Ответ 9

Я не вижу, как логирование (удаление прав пользователя) является дескриптивным действием. Дело в том, что действие "выход из системы" должно быть доступно только пользователям, которые уже вошли в систему иначе, это было бы устаревшим.

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