Вопрос: Можете ли вы передать пользователь / пароль для базовой проверки подлинности HTTP в параметрах URL?


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

Я пытался http://myserver.com/~user=username&password=mypassword но это не сработает.

Можете ли вы подтвердить, что на самом деле невозможно передать пользователю / пройти через параметры HTTP (GET или POST)?


115
2018-03-21 11:16


Источник


Пользователь: pass@example.com - Smudge
@sam - что? Как будет выглядеть весь URL? - ripper234
Все в спецификации ietf.org/rfc/rfc1738.txt (3.1) - Smudge
@sam - Извините, я просто не смог разобрать ваш комментарий по какой-то причине. - ripper234


Ответы:


Невозможно передать имя пользователя и пароль через параметры запроса в стандартном HTTP-аутентификации. Вместо этого вы используете специальный формат URL, например: http://username:password@example.com/ - это отправляет учетные данные в стандартный HTTP-заголовок «Авторизация».

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


157
2018-03-21 11:38



Спасибо, это именно то, что я искал ... не важно, что это параметры GET, просто я могу создать его в URL. - ripper234
FYI, http://username:password@example.com формат больше не поддерживается IE или Хром, не удивился бы, если бы другие последовали этому примеру, если они еще этого не сделали. - T.J. Crowder
На самом деле отлично работает в Chrome. Только IE - испорченный брат. - Damien Overeem ツ
@DamienOvereem какая версия хром вы? я нахожусь на mac os x 37, и это, кажется, не работает для меня - Chris DaMour
С тех пор я узнал, что Chrome отключил его некоторое время, но позже включил эту функцию. Я также узнал, что Safari будет вызывать ошибки фишинга при работе с этими типами ссылок. В основном время аутентификации на основе URL-адреса завершено. - Damien Overeem ツ


Http: // имя пользователя: password@example.com будет работать для FireFox, Chrome, Safari, но не для IE.

База знаний Microsoft


15
2018-01-23 10:50



Эта возможность была удалена из Chrome 19+. Видеть code.google.com/p/chromium/issues/detail?id=123150 - Moshe Katz
Читая этот отчет об ошибке, он снова добавлен в Chrome 20. Конечно, я бы ожидал увидеть много продолжающих жаловаться на это, если бы этого не было. - womble♦
Теперь я запросил его для Internet Explorer: connect.microsoft.com/IE/feedback/details/873575/..., Немного другой вариант использования, но касается той же проблемы;) - SimonSimCity
@Diago, если пароль содержит «@», тогда это не сработает. это приводит к фатальной ошибке, может ли кто-нибудь сказать мне, как мы можем сразу указать имя пользователя и пароль - Ashish Jain
@AshishJain - я бы попытался убежать @ в качестве пароля %40, (Я не знаю, работает ли это, и это может зависеть от комбинации сервера или браузера / сервера). - David Moles


Передача основных параметров проверки подлинности в URL не рекомендуется

Для этого есть поле заголовка авторизации, чтобы проверить его здесь: Список заголовков http

Как его использовать: Основная аутентификация доступа

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

Читайте также глава 4.1 в RFC 2617 - HTTP-аутентификация для более подробной информации о том, почему НЕ использовать базовую аутентификацию.


Передача параметров аутентификации в строке запроса

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

GET https://www.example.com/api/v1/users/1?access_token=1234567890abcdefghijklmnopqrstuvwxyzABCD

14
2017-09-24 07:55



И как сделать кодировку заголовка авторизации в URL? - womble♦
Разве это не та формулировка, которую вы заявили, теперь не рекомендуется? - womble♦
Вопрос, на который вы ответили: «Для этого есть поле заголовка авторизации», было задано вопрос о том, как установить параметры аутентификации в URL-адрес, Если вы не можете закодировать поля заголовка HTTP в URL-адрес (который вы не можете), ваш ответ является нелогичным. - womble♦
Можете ли вы указать, где в стандарте URI указано, что прохождение базовых параметров аутентификации в URI устарело? RFC 2396 только говорит, что он «НЕ РЕКОМЕНДУЕТСЯ», потому что данные аутентификации в обычном тексте во многих случаях не являются хорошей идеей (о чем я согласен), в то время как RFC 7235 ничего не говорит. Нигде в спецификациях, которые я могу найти, говорится, что он устарел. - Lie Ryan
@Wilt: Я должен извиниться, ты действительно прав. Ваш намек на то, что спецификация была «изменена», подтолкнула меня к дальнейшему расследованию (RFC никогда не изменяется после публикации / пронумерования). Я только что нашел, что RFC 2396 фактически был заменен RFC 3986, которого я не смог найти раньше. RFC 3986 упоминает устаревшее имя пользователя: синтаксис пароля: Use of the format "user:password" in the userinfo field is deprecated. - Lie Ryan


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

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


0
2017-09-11 08:22