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

153

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

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

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

authentication http http-basic-authentication

— ripper234
источник

9

пользователь: pass@example.com

— Smudge

@ Сам - что? Как будет выглядеть полный 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.

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

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