Разработка RESTful сервиса входа в систему

Question

Я прошел похожий вопрос здесь . Но я еще не ясно, концепции. Вот мой сценарий ...

Мой клиент (приложение для мобильных устройств) имеет экран входа в систему для ввода имени пользователя и пароля. После отправки он должен увидеть список книг в базе данных плюс список книг, подписанных этим пользователем.

У меня / LoginService, который принимает имя пользователя, пароль и проверяет базу данных mysql на проверку учетных данных. Только после авторизации .... У меня есть / BookService; ПОЛУЧИТЬ, что возвращает все книги в базе данных.

1. Должен ли я использовать GET, POST или PUT на моем сервисе входа? Поскольку запрос на вход в систему является операцией только для чтения, я должен использовать GET - но это выглядит глупо для браузера (так как представленные данные видны).

2. Что такое токены доступа (упомянутые в связанном ответе выше) и как их генерировать с помощью Java? Я использую Джерси для развития. Это безопасный способ авторизации?

Спасибо!

Answer 1

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

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

1. Клиент может предоставить имя пользователя и пароль через заголовки HTTP (нестандартный, что-то вроде Имя пользователя: пользователь и Пароль: секретный ).
2. На стороне сервера вы можете использовать
   1. Используйте АОП: просто оберните вас BooksService с помощью AuthAdvice (что вы должны написать сами). Советуем вам как-нибудь (с функциональностью Джерси) получить доступ к HTTP-запросу, взять из него соответствующие заголовки, аутентифицировать и авторизовать пользователя (загружаемого из БД), ввести пользователя в ThreadLocal (чтобы он был доступен для остальной части вашего приложения). ) при необходимости и просто вызовите соответствующий метод или сгенерируйте исключение, если что-то не так с учетными данными.
   2. Используйте функциональность Джерси: (извините, я не очень знаком с Джерси, я использую CXF, но концептуально это должно быть то же самое), просто создайте какой-нибудь AuthHendler и вставьте его в Запрос предварительной обработки конвейера. В этом обработчике вам нужно сделать то же самое, что и в AuthAdvice

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

Если вы хотите пройти весь путь, вы можете просто использовать HttpSession. LoginService.login() должен быть запрос POST, потому что вы действительно делаете некоторые побочные эффекты на сервере. Сервис выполнит аутентификацию вашего пользователя в соответствии с предоставленными именем пользователя и паролем и поместит загруженный объект User в сеанс. На этом этапе сеанс на стороне сервера создается, и у клиента есть идентификатор сеанса в файлах cookie. Поэтому дальнейшие запросы должны автоматически отправлять его на сервер. Чтобы авторизовать запросы к BooksService, вам все еще нужен какой-то совет обработчика (см. Решение без сохранения состояния). Единственное отличие: на этот раз пользователь берется из HttpSession (вы должны убедиться, что вы вошли в систему!).

Обновление: И использование HTTPS ! :)

Answer 2

Мне нечего оспаривать в ответе Easy Angel, но у меня сложилось впечатление, что вам также понадобятся дополнительные комментарии к концепциям.

Проблема проясняется, если подумать о ресурсах , а не услугах . Думайте о том, что предлагаемый вами логин генерирует новый ресурс авторизации, а не запрашивает сервис логина. Тогда вы видите, что POST имеет смысл.

Токен авторизации будет ключом для вашего пользователя в объекте сеанса (как объяснено в ответе EA). Возможно, вы захотите сгенерировать его, объединяя некоторую информацию, которая однозначно идентифицирует этого пользователя, и хешируя ее. Я, конечно, согласен, что метод аутентификации без сохранения состояния предпочтительнее, если вы стремитесь получить все преимущества REST.

Answer 3

Используйте то, что доступно в HTTP: HTTP AUTH через SSL. Защитите все свои ресурсы с помощью HTTP AUTH, и браузер позаботится о том, чтобы предоставить логин для пользователя.

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