Как работают серверы без сохранения состояния?

Question

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

Как настроить Spring-Security для этого?

Answer 1

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

В Java вы можете сделать его без сохранения состояния, используя куки для хранения учетных данных или используя распределенные хэши. Обычно люди соглашаются использовать что-то вроде memcache и говорят, что они не имеют состояния, потому что состояние хранится вне веб-сервера. Это позволяет пользователю использовать любой веб-сервер в ферме и при этом безопасно проходить проверку подлинности. В Java у нас есть много распределенных реализаций хеша, которые вы можете использовать с Spring, поэтому вам не нужно использовать memcache для этого.

Другой вариант - использовать куки для хранения криптографического безопасного хэшированного билета, называемого HMAC. Использование файлов cookie позволяет избежать использования сеанса, поэтому веб-сервер не имеет состояния. С HMAC вы можете подписать блок данных, который не может быть подделан или создан третьей стороной и гарантированно будет получен от вас. Это не требует ресурсов внешнего сервера (кеша) для аутентификации пользователя, поэтому он может масштабироваться лучше, но есть некоторые проблемы безопасности, о которых вы должны знать. К вашему сведению, Google использует эту технику для горизонтального масштабирования. Один HMAC не похож на SHA1 или другие кирпохеши. Им требуется секретный ключ, который должен находиться на каждом сервере в ферме. Это также должно быть защищено симметричным ключом шифрования, чтобы убедиться, что он надежно хранится на сервере, если кто-то завладеет файлом. Кроме того, информация HMAC хранится в открытом виде, так что, хотя вы можете поместить имя пользователя или адрес электронной почты в файл cookie, реальный крипто-хеш доступен для всех. Если кто-то завладеет этим файлом cookie, он может маскироваться под этого пользователя. Вот почему HMAC, как правило, действительны только в течение определенного периода времени. После этого срок действия истекает, поэтому, если кто-то завладеет им, он не сможет получить доступ к этой учетной записи навсегда.

Таким образом, HMAC имеют этот недостаток, и вы должны быть осторожны с тем, в каких приложениях вы их используете. Для Paypal было бы очень плохой идеей использовать эту схему, потому что все, что мне нужно сделать, это получить ваш безопасный cookie, а затем перевести все ваши средства мне. Большой плюс в том, что ваше приложение действительно без сохранения состояния.

Последний вариант - хранить ваши Java-сессии в распределенном хеше. Php и другие платформы будут выгружать свои сеансы в базу данных, распределенный кеш бедного человека или сбрасывать их в memcache. С Java вы можете сделать то же самое. Вы также можете помещать свои сеансовые объекты в распределенный кеш. Этот вариант потерял популярность, потому что люди думают: «Круто, теперь я могу добавить все, что захочу, в свою сессию, и это будет без сохранения состояния». Однако, как и для всех распределенных кэшей, существуют ограничения по скорости передачи, времени репликации и размеру полезной нагрузки. Это верно для Java или Memcache. Держите ваши сессии небольшими, и это работает хорошо. Добавьте все в сеанс, и вы вернетесь к проблемам масштабирования, которые у вас возникают с одним сервером. И на самом деле это, вероятно, хуже, чем если бы вы только что сделали свой сервер состоящим из состояния, потому что иногда грид-вычисления хуже, чем один сервер.

Обновление: вот список библиотек распределенного кэширования Java, которые вы можете использовать для этого:

http://www.manageability.org/blog/stuff/distributed-cache-java

Answer 2

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

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

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

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