Как вы передаете данные авторизации с помощью запроса HTTP GET в системе RESTful? - PullRequest
Новая
       13

Как вы передаете данные авторизации с помощью запроса HTTP GET в системе RESTful?

4 голосов
/ 17 августа 2011

Это, наверное, самый основной вопрос и по какой-то причине, но я немного ошеломлен. Я проектирую спокойный сервис, который имеет несколько страниц. При нажатии на ссылку по умолчанию запускается HTTP GET

Теперь как отправить данные авторизации с запросом на получение? Должен ли он быть частью URL? Я буду вынужден создать уродливый URL с зашифрованными параметрами запроса. Есть ли способ избежать этого?

Есть ли в javascript / jquery что-то, что могло бы просто отправить эти данные, так сказать, "под капот"?

в JQuery метод $.ajax принимает username, password в качестве аргументов, чтобы данные авторизации можно было отправлять вместе с вызовом ajax. Что-нибудь эквивалентное для вызовов не-AJAX, или я оставил только URL?

Причина такого подхода:

  • Я хочу, чтобы пользователь мог нажать кнопку «Назад» и вернуться на предыдущую страницу. Если бы я сделал $.get с авторизацией и следовал за ней с $('html').replaceWith(result), это бы отключило кнопку возврата, правильно? (т.е. ничего не показывать)

Вероятно, это должен быть ОТДЫХ 101, но по какой-то причине меня загнали в угол

(К вашему сведению: технологии: Jquery / Javascript / Restlet / Freemarker)

(PS: Печенье как последнее средство. Или это лучший способ?)

1 Ответ

2 голосов
/ 17 августа 2011

С запросами GET вы ограничены заголовками запроса и строкой запроса / URL вашего запроса. Вы можете использовать HMAC подход или OAUTH , где каждый запрос «подписан». Если вы делаете это исключительно на стороне клиента, существует проблема с общим секретом, который больше не является, ну, в общем, секретным.

Конечно, похоже, что вы уже делаете POST-запросы, используя имя пользователя и пароль (что я очень не рекомендую, кстати)

Если вам нужны примеры HMAC в действии, я полагаю, что Amazon использует (или использовала) HMAC для взаимодействия с S3, поэтому существует множество примеров кода.

В конечном итоге, веб-клиенту очень трудно выполнить аутентификацию без сохранения состояния без раскрытия некоторой «секретной» информации, такой как пароли или закрытые ключи / токены. Вы можете выдать временные токены пользователю, которые затем будут зарезервированы, проверив, что заголовки запроса (IP-адрес и т. Д.) Согласованы в течение срока службы токена. Если вы раскрываете временные токены клиенту, вы, вероятно, захотите, чтобы ваш механизм аутентификации включал также уникальный nonce для запроса.

Чисто RESTful-аутентификация без сохранения состояния нетривиальна, если вы хотите, чтобы веб-клиент выполнял запросы, поэтому я бы не назвал ее REST 101:)

...