Настройка заголовка HTTP авторизации

Question

Настройка заголовка HTTP авторизации

мне нужно аутентифицировать клиента, когда он отправляет запрос в API. У клиента есть API-токен, и я думал об использовании стандартного Authorization заголовок для отправки маркера на сервер.

обычно этот заголовок используется для Basic и Digest проверка подлинности. Но я не знаю, Могу ли я настроить значение этого заголовка и использовать пользовательскую схему auth, например:

Authorization: Token 1af538baa9045a84c0e889f672baf83ff24

вы бы порекомендовали это или нет? Или есть лучший подход к отправке токен?

1458 5

http-headers rest http api authorization

5 ответов:

Comments

Ничего не найдено.

DaveRandom · Accepted Answer · 2011-12-11 15:30:45

вы можете создать свои собственные схемы аутентификации, которые используют Authorization: заголовок-например, вот как OAuth строительство.

как правило, если серверы или прокси не понимают значения стандартные заголовки, они оставят их в покое и игнорировать их. Это создание собственного заголовка ключи это часто может привести к неожиданным результатам-многие прокси будут удалять заголовки с именами, которые они не распознают.

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

другой момент заключается в том, что многие клиентские библиотеки HTTP имеют встроенную поддержку Digest и Basic auth, но могут сделайте жизнь более сложной при попытке установить необработанное значение в поле заголовка, тогда как все они обеспечат легкую поддержку файлов cookie и позволят более или менее любое значение в них.

Abhishek Kumar · Accepted Answer · 2018-08-08 12:08:38

в случае КРЕСТ ПРОИСХОЖДЕНИЕ просьба прочитать это:

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

Authorization заголовок считается пользовательским заголовком. Поэтому, если междоменный запрос выполняется с помощью Autorization набор заголовков, браузер сначала отправляет предварительный запрос. Предполетный запрос является HTTP-запросом методом OPTIONS, этот запрос удаляет все параметры из запроса. Ваш сервер должен ответить с Access-Control-Allow-Headers заголовок, имеющий значение вашего пользовательского заголовка ().

таким образом, для каждого запроса, который отправляет клиент (браузер), браузер отправляет дополнительный HTTP-запрос(параметры). Это ухудшило производительность моего API. Вы должны проверить, если это ухудшает производительность. В качестве обходного пути я отправляю токены в параметрах http, которые, как я знаю, не лучший способ сделать это, но я не мог компромисс с производительностью.

Steve Dearborn · Accepted Answer · 2015-11-04 18:31:58

Это немного устарело, но могут быть и другие, ищущие ответы на тот же вопрос. Вы должны подумать о том, какие пространства защиты имеют смысл для ваших API. Например, может потребоваться идентифицировать и аутентифицировать доступ клиентских приложений к API, чтобы ограничить их использование известными зарегистрированными клиентскими приложениями. В этом случае, вы можете использовать Basic схема аутентификации с идентификатором клиента в качестве идентификатора пользователя и общим секретом клиента в качестве пароля. Тебе это не нужно проприетарные схемы аутентификации просто четко определяют один (ы), которые будут использоваться клиентами для каждого пространства защиты. Я предпочитаю только один для каждого пространства защиты, но стандарты HTTP позволяют использовать как несколько схем аутентификации на каждом ответе заголовка WWW-Authenticate, так и несколько заголовков WWW-Authenticate в каждом ответе; это будет запутанным для клиентов API, какие параметры использовать. Будьте последовательны и понятны, тогда ваши API будут использоваться.

Julian Reschke · Accepted Answer · 2011-12-11 15:53:33

Я бы рекомендовал не использовать аутентификацию HTTP с пользовательскими именами схем. Если вы чувствуете, что у вас есть что-то общее использование, вы can определить новую схему, хотя. См.http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-latest.html#rfc.section.2.3 Подробнее.

Madan Dale · Accepted Answer · 2017-05-21 10:33:26

пожалуйста, попробуйте ниже на почтальона :-

в разделе заголовка пример работы для меня..

авторизация: JWT