определение веб-методов аутентификации HTTP
Как Вы определяете, использует ли веб-сервис REST Основной, Kerberos, NTLM или один из многих других методов аутентификации?
3 ответа
Когда вы посылаете неаутентифицированный запрос, служба должна ответить "HTTP/1.1 401 Unauthorized", а ответ содержит заголовок WWW-Authenticate, который указывает, какая схема аутентификации ожидается (Basic, Digest), область безопасности и любое другое специфическое значение (например, nonce Digets). Таким образом, если сервер отвечает:
HTTP/1.0 401 Unauthorized
WWW-Authenticate: Digest realm="example.com",
qop="auth,auth-int",
nonce="...",
opaque="..."
он хочет получить Digest-аутентификацию. Если ответ выглядит как:
HTTP/1.0 401 Unauthorized
WWW-Authenticate: Basic realm="example.com"
- значит, он хочет пройти базовую аутентификацию. Некоторые (плохо) реализованные серверы/сайты не обрабатывают Basic правильно и отвечают прямо 403 Forbidden вместо первого запроса.
NTLM аналогичен, поскольку сервер отвечает 401 и заголовком WWW-Authenticate со значением NTLM, но для него нет официальной публичной спецификации, поскольку он является собственностью Microsoft. Существуют различные обратные инженерные описания.
К сожалению, REST не поставляется с описанием службы в стиле WSDL для обнаружения используемой схемы аутентификации a priori.
Если это сценарий черного ящика, я обычно подключаюсь к Fiddler , и проверить фактический трафик.
Вы отправляете ему запрос, предположительно получаете код HTTP 401 и просматриваете заголовок WWW-Authenticate , который (согласно RFC 2616 ) ответ ДОЛЖЕН ] включают. Если вместо этого вы получаете 403 или какой-либо другой странный статус или отсутствующий заголовок WWW-Authenticate , вы ругаетесь на авторов веб-сайтов, которые не следуют основному HTTP RFC, и начинаете прослушивать трафик, чтобы попытаться отменить спроектируйте, какой нестандартный беспорядок они натворили в этот раз ;-).