Аутентификация базового HTTP и идентификатора подписчика

В настоящее время я разрабатываю REST-API, который защищен HTTP-базой для среды разработки. Поскольку реальная аутентификация выполняется через токен, я все еще пытаюсь выяснить, как отправить два заголовка авторизации.

Я пробовал это:

curl -i http://dev.myapp.com/api/users \
  -H "Authorization: Basic Ym9zY236Ym9zY28=" \
  -H "Authorization: Bearer mytoken123"

Я мог бы, например, отключить HTTP-аутентификацию для своего IP-адреса, но поскольку я обычно работаю в разных средах с динамическими IP-адресами, это не очень хорошее решение. Так что я чего-то не хватает?

Ответ 1

Попробуйте это сделать, чтобы выполнить базовую аутентификацию по URL:

curl -i http://username:[email protected]/api/users -H "Authorization: Bearer mytoken123"
               ^^^^^^^^^^^^^^^^^^

Если выше один не работает, то вы не имеете к этому никакого отношения. Поэтому попробуйте следующие альтернативы.

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

curl -i http://dev.myapp.com/api/users \
  -H "Authorization: Basic Ym9zY236Ym9zY28=" \
  -H "Application-Authorization: mytoken123"

Заметьте, что я изменил заголовок на Application-Authorization. Поэтому из вашего приложения поймайте токен под этим заголовком и обработайте то, что вам нужно сделать.

Еще одна вещь, которую вы можете сделать, - передать параметры token через POST и захватить значение параметра со стороны сервера. Например, передавая токен с параметром curl post:

-d "auth-token=mytoken123"

Ответ 2

Стандарт (https://tools.ietf.org/html/rfc6750) говорит, что вы можете использовать:

Форма кодированного тела: авторизация: Bearer mytoken123
Параметр запроса URI: access_token = mytoken123

Таким образом, можно пропускать многозначный токен с URI, но делать это не рекомендуется (см. раздел 5 в стандарте).

Ответ 3

curl --anyauth

Сообщает завиток, чтобы выяснить метод аутентификации сам по себе, и использовать наиболее безопасный, который заявляет удаленный сайт для поддержки. Это делается путем сначала выполнив запрос и проверив заголовки ответа, таким образом возможно, вызвав дополнительную сеть в оба конца. Это используется вместо установки определенного метода проверки подлинности, который вы можете делать с - basic, --digest, --ntlm и --negotiate.