Лицензии и сеансы RESTful

Этот вопрос перешел мне в голову после того, как я прочитал этот пост: Общие ошибки REST: сеансы неактуальны

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

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

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

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

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

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