Вы можете передать user / pass для HTTP Basic Authentication в параметрах URL?

153

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

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

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

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

Ответы:

200

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

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

romble
источник
1
Спасибо, это именно то, что я искал ... это не критично, что это параметры GET, просто я могу встроить его в URL.
ripper234
42
К вашему сведению, http://username:password@example.comформат больше не поддерживается ни IE, ни Chrome , поэтому не удивлюсь, если другие последуют его примеру, если они этого еще не сделали.
TJ Crowder
11
На самом деле прекрасно работает в Chrome. Только IE - испорченный ребенок.
Дэмиен Оверим ツ
1
@DamienOvereem, на какой версии Chrome вы работаете? Я нахожусь на Mac OS x 37, и это, кажется, не работает для меня
Крис Дамур
11
С тех пор я узнал, что Chrome отключил его на некоторое время, но позже снова включил эту функцию. Я также узнал, что Safari будет выдавать фишинговые ошибки при работе с ссылками такого типа. По сути, время http-аутентификации на основе URL истекло ..
Дэмиен Оверим
18

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

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

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

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

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


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

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

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

http: // username: password@example.com будет работать для FireFox, Chrome, Safari, НО не для IE.

База знаний Microsoft

Гириш Кумар
источник
2
Эта возможность была удалена из Chrome 19+. См. Code.google.com/p/chromium/issues/detail?id=123150
Моше Кац,
4
После прочтения этого отчета об ошибках он был добавлен в Chrome 20. Конечно, я ожидал бы увидеть много продолжающих жаловаться на него, если бы этого не было.
womble
Теперь я запросил его для Internet Explorer: connect.microsoft.com/IE/feedback/details/873575/… . Немного другой
сценарий
@Diago, если пароль содержит «@», значит, он не работает. это дает фатальную ошибку, может кто-нибудь сказать мне, как мы можем дать имя пользователя и пароль сразу
Ашиш Джайн
@AshishJain - я бы попробовал экранировать @пароль %40. (Я не знаю, работает ли это, хотя, и это может зависеть от комбинации сервер или браузер / сервер.)
Дэвид Молес
0

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

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

Стив Смит
источник