Лицензии и сеансы с помощью RESTful

Question

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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