Лицензии и сеансы ОТЛИЧНЫЙ способ

Question

Этот вопрос приходил мне в голову после прочтения этого поста: «Типичные ошибки REST: сессии не имеют значения»

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

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

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

Есть ли альтернатива? в частности, более RESTful альтернатива?

Answer 1

Позвольте мне попытаться соединить точки для вас, если я правильно истолковал ваш вопрос. Ссылка, которую вы разместили, имеет правильный ответ, каждый запрос должен использовать HTTP-аутентификацию. Если вам нужна концепция лицензий для поддержания определенного состояния для вашего пользователя, вы, скорее всего, можете связать это с пользователем. У вас есть (подтвержденное) имя пользователя. Вам просто нужно вызывать этот контроллер для каждого запроса и сохранять его состояние. Там у вас есть сеанс.

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

Answer 2

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

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

Answer 3

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

Не зная деталей вашей инфраструктуры, сложно дать конкретную рекомендацию. Используя в качестве примера платформу * nix, логику обработки лицензий можно реализовать в виде модуля для HTTP-сервера Apache.

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

Answer 4

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