Веб-приложение без гражданства, городская легенда?

Я пытаюсь понять token-based authentication в эти дни, который утверждает, что является stateless authentication методом. И я встретил концепцию stateless web application.

Ниже приведены некоторые темы, о которых я читал:

Сначала я был в восторге от этой идеи. Но все больше и больше я думаю, что stateless - это pseudo-proposition.

Например, предположим, что мы используем сохраненный клиентом токен для аутентификации, как мы можем сделать статистику онлайн-пользователей (предположим, что нет журнала)? Будем ли мы хранить маркер в БД? Разве это не означает, что мы храним информацию о состоянии на сервере? И даже больше, это простая информация о пользователе, такая как имя, возраст и т. д. в БД тоже какая-то информация о состоянии?

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

Это зависит от того, как интерпретировать слово stateless:
  1. веб-приложение не имеет состояния.
  2. или веб-приложение не хранит состояние само по себе.

Я предпочитаю 2, потому что всегда может быть какой-то inevitable global state (цитирую комментарий @deceze к его ответу). И неважно, что мы храним информацию о состоянии в виде веб-хранилища HTML 5 или HTTP заголовок, или скрытые поля формы, или куки, состояние все еще существует. Только то, что он хранится не на сервере, а где-то еще.

Я упускаю что-то великое? Может ли кто - нибудь пролить свет на это, чтобы я мог освободиться от этой умственной борьбы?

Добавить 1

Просто прочитайте о книге RESTful Web Services by Leonard Richardson. В главе 4, в конце раздела Statelessness, он классифицирует состояние на Application State и Resource State. Итак, простая информация о пользователе и данные I упоминалось ранее, как изображения и т. д. можно классифицировать как Resource State. И то, что stateless относится к Application State. Таким образом, он не нарушает код апатридов для хранения resource state на сервере.

Но в книге также упоминается сценарий, в котором an application key is used to restrict how many times a user can invoke a web service. признается, что такая информация не может храниться на стороне клиента. А необходимость хранить его на стороне сервера нарушает код апатридов и вводит проблему сходства сеансов. Он утверждает, что апатриды могут избежать проблемы сходства сеансов, но не объясняет, как это сделать. Я действительно не вижу, как апатриды могут справиться с этим сценарием. Кто-нибудь может пролить здесь свет?
3 9
http token session stateless

3 ответа:

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

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

Рассмотрим: при традиционном сеансе входа в систему на основе файлов cookie сервер находится только в состоянии принимать запросы от клиентав течение ограниченного временного окна; до тех пор, пока текущий сеанс действителен. Клиент не может предсказать, как долго это будет продолжаться. В любой момент запрос от клиента может завершиться ошибкой, так как некоторое состояние на сервере истекло. В этом случае клиент должен сбросить состояние сервера, снова войдя в систему.

Сравните это с токеном основанная аутентификация. Маркер должен быть действителен неограниченно долго. По сути, это замена имени пользователя и пароля. Для обсуждения предположим, что клиент отправляет свое имя пользователя и пароль при каждом запросе. Это означает, что каждый запрос может быть аутентифицирован по своим собственным достоинствам, не требуя, чтобы сервер находился в каком-то определенном временном "состоянии".

Причина, по которой вы используете токены вместо имен пользователей и паролей, двояка:

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

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

Последний потенциальный аргумент, который нуждается в упреждающем противодействии: в чем разница между неопределенной сессией и неопределенным токеном, и в чем разница, когда сессия заканчивается и когда токен может быть отозван?
Когда сеанс заканчивается, его можно восстановить, используя некоторые другие "основные учетные данные" (вход в систему). Токен может/должен заканчиваться только при активном отзыве, что сродни отзыву разрешение на доступ к службе полностью для основных учетных данных и не является частью обычного потока приложений.

Говоря более обобщенно: сравните протокол HTTP без состояния с протоколом с сохранением состояния, таким как FTP. В FTP сервер и клиент должны поддерживать общее состояние в синхронизации. Например, протокол FTP имеет, помимо всего прочего, команду CWD для изменения текущего рабочего каталога. То есть, есть понятие о том, что каталог a клиент "находится внутри" в любой момент времени. Последующие команды ведут себя по-разному в зависимости от того, в каком каталоге они находятся. Это очень важно для государства. Вы не можете произвольно посылать команды, не зная об этом состоянии, иначе вы не сможете предсказать, каким будет результат.

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

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

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

11

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

Таким образом, в вашем случае, если вы отправляете токен auth с каждым запросом, то он не имеет состояния. Вот как должна работать аутентификация HTTP.

С другой стороны, если бы вы отправляли токен auth только один раз и каждый последующий запрос не был бы обязан (например, потому что сервер знает, что это TCP-соединение уже аутентифицировано), то это означает, что каждый запрос зависит от запроса аутентификации. Это делает протокол статусным.

Протоколы без состояния легче масштабировать, проще проксировать и т. д.

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

Примечание: сохранение состояния / без состояния не связано с обменом данными между клиентом и сервером.

4

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

Аутентификация без состояния-это метод идентификации личности клиента без передачи какой-либо информации/состояния из предыдущего запроса клиента или взаимодействия, в отличие, например, от файлов cookie.

Веб-приложения без состояния? Конечно, они возможны, но это полностью зависит от того, должны ли сохраняться пользовательские данные, то есть, это действительно зависит от рассматриваемого приложения.

1