Этот вопрос не о том, когда использовать GET или POST в целом; это то, что рекомендуется для выхода из веб-приложения. Я нашел много информации о различиях между GET и POST в общем смысле, но я не нашел определенного ответа для этого конкретного сценария.
Как прагматик, я склонен использовать GET, потому что реализовать его намного проще, чем POST; просто оставьте простую ссылку, и все готово. Это, кажется, имеет место с подавляющим большинством веб-сайтов, о которых я могу думать, по крайней мере, из головы. Даже Stack Overflow обрабатывает выход с помощью GET.
Мое сомнение вызывает (хотя и старый) аргумент, что некоторые веб-акселераторы / прокси-серверы предварительно кэшируют страницы, просматривая и извлекая каждую ссылку, найденную на странице, поэтому пользователь получает более быстрый ответ, когда нажимает на них. Я не уверен, что это все еще применимо, но если бы это было так, то теоретически пользователь с одним из этих ускорителей будет выгнан из приложения, как только он войдет в систему, потому что ее ускоритель найдет и получит выход из системы. ссылку, даже если она никогда не нажимала на нее.
Все, что я прочитал до сих пор, говорит о том, что POST следует использовать для «разрушительных действий», тогда как действия, которые не изменяют внутреннее состояние запросов, подобных запросам и тому подобное, должны обрабатываться с помощью GET . Исходя из этого, реальный вопрос здесь:
Считается ли выход из приложения разрушительным действием или он изменяет внутреннее состояние приложения?
источник
Ответы:
Использование
POST
.В 2010 году использование
GET
было, вероятно, приемлемым ответом. Но сегодня (в 2013 году) браузеры будут предварительно выбирать страницы, которые, по их мнению, вы посетите в следующий раз.Вот один из разработчиков StackOverflow, который говорит об этой проблеме в твиттере:
Интересный факт: StackOverflow используется для обработки выхода через GET, но не больше.
источник
В REST не должно быть сессии, поэтому уничтожать нечего. REST-клиент аутентифицируется при каждом запросе. Вход или выход, это просто иллюзия.
Вы действительно спрашиваете, должен ли браузер продолжать посылать аутентификационную информацию при каждом запросе.
Возможно, если ваше приложение создает иллюзию входа в систему, то вы должны иметь возможность «выйти», используя javascript. Не требуется поездка туда и обратно.
Филдинг Диссертация - раздел 5.1.3
источник
httponly
атрибутом, чтобы предотвратить некоторые риски xss, что означает, что его можно сбросить только с сервера (если не считать ручную очистку cookie-файла)Одним из способов
GET
злоупотребления здесь может быть то, что человек (возможно, конкурент :) разместил в Интернете тег с изображениемsrc="<your logout link>"
ЛЮБОГО ВЕЗДЕ, и если пользователь вашего сайта наткнется на эту страницу, он будет по незнанию отключен от системы.источник
/logout
URL-адреса в скрытых изображениях), и это работает.Чтобы быть точным, GET / POST (или другие глаголы) являются действиями над некоторым ресурсом (адресуемым URL-адресом), так что обычно речь идет о состоянии ресурса, а не о состоянии приложения как такового. Таким образом, в истинном настроении у вас должен быть URL, например
[host name]\[user name]\session
, тогда «DELETE» будет правильным глаголом для действия выхода из системы.Использование в
[host name]\bla bla\logout
качестве URL не совсем полноценного REST (IMO), так зачем спорить о правильном использовании GET / POST для него?Конечно, я также использую GET для выхода из URL в своих приложениях :-)
источник
Выход из системы никак не влияет на само приложение. Изменяет состояние пользователя по отношению к приложению. В этом случае кажется, что ваш вопрос больше основан на том, как команда должна быть инициирована пользователем, чтобы начать это действие. Поскольку это не «разрушительное действие», убедитесь, что сеанс отменен или уничтожен, но ни ваше приложение, ни ваши данные не изменены, поэтому невозможно, чтобы оба метода инициировали процедуру выхода из системы. Сообщение должно использоваться любыми действиями, инициированными пользователем (например, пользователь нажимает кнопку «Выйти»), в то время как get может быть зарезервировано для инициированных приложением выходов из системы (например, - исключение, обнаруживающее потенциальное вторжение пользователя, принудительно перенаправляет на страницу входа с выходом из системы GET ).
источник
Здравствуйте, с моей точки зрения, когда вы входите в систему, вы проверяете имя пользователя / пароль и, если они совпадают, вы создаете токен для входа.
CREAT token => метод POST
Когда вы выходите из системы, вы уничтожаете токен, поэтому для меня наиболее логичным должен быть метод DELETE.
УДАЛИТЬ токен => метод УДАЛИТЬ
источник
Сценарий предварительного кэширования интересен. Но я предполагаю, что если на многих сайтах в т.ч. не стоит об этом беспокоиться, то, возможно, вам тоже не стоит.
Или, может быть, ссылка может быть реализована в JavaScript?
Изменить: Как я понимаю, технически GET должен быть для запросов только для чтения, которые не изменяют состояние приложения. POST должен быть для запросов на запись / редактирование, которые изменяют состояние. Однако другие проблемы приложения могут предпочесть GET, а не POST для некоторых запросов на изменение состояния, и я не думаю, что есть какие-либо проблемы с этим.
источник
Что ж, если вы позволите своему веб-приложению отказаться от сеанса с помощью сценария выхода из системы, вам обычно это тоже не нужно. Обычно есть переменная сеанса, уникальная для сеанса, который вы хотите отменить.
источник
Недавно я работал над проектом, использующим GET для выхода из системы. Ниже приведен код в Nodejs Express, и он прекрасно работает.
ваш router.js
ваш controller.js
источник
Я не вижу, как выход из системы (снижение прав доступа пользователей) является деструктивным действием. Это связано с тем, что действие «выход из системы» должно быть доступно только пользователям, которые уже вошли в систему, иначе оно будет устаревшим.
Случайно сгенерированная строка, содержащаяся в файлах cookie вашего браузера, представляет собой сеанс пользователя. Существует множество способов его уничтожить, поэтому эффективный выход из системы - это просто услуга для вашего посетителя.
источник
wget
в режиме паука с правильным файлом cookie сеанса на частной вики я должен был однажды сделать это. Конечно, один из первых просканированных URL был/logout
./logout
страницам. Например, вам придется снова войти в Gmail, снова войти в чат, найти свое место в любых разговорах в Hangouts, которые вы прокручивали и т. Д., И это только для Google.com.