Как передать вопросительный знак (?) в пароле для базовой аутентификации HTTP в параметрах URL?

Как передать вопросительный знак (?) в пароле для базовой аутентификации HTTP в параметрах URL?

Я автоматизирую веб-сайт, требующий базовой аутентификации HTTP.

Предложения, приведенные по этой ссылке, в большинстве случаев работают как по волшебству:

Можно ли передать имя пользователя/пароль для базовой аутентификации HTTP в параметрах URL?

Однако у некоторых пользователей ?в пароле есть вопросительный знак ( ). Пожалуйста, посоветуйте, как обойти вопросительный знак.

PS Я знаю, что @имя пользователя можно экранировать как %40.

решение1

Я полагаю, вы, должно быть, имеете в видуинформация о пользователечасть URL, в которой передаются учетные данные пользователя, а не «параметры URL» (которые являются частьюСтрока запроса):

https://<userinfo>@example.com/foo?<query-string>

Как и любой символ, который не допускается в какой-либо части URL (поскольку он может иметь особое значение), он должен быть закодирован в URL (процентно-кодированный), за которым %следует двузначный шестнадцатеричный код этого символа.

Так что, @есть %40и ?есть %3F.

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

RFC3986определяет, какие символы разрешены (незакодированы) винформация о пользователечасть URL-адреса:

userinfo    = *( unreserved / pct-encoded / sub-delims / ":" )
unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded = "%" HEXDIG HEXDIG
sub-delims  = "!" / "$" / "&" / "'" / "(" / ")"
              / "*" / "+" / "," / ";" / "="

Таким образом, все остальное должно быть закодировано процентами, включая :и %- если они являются частьюпользовательилипарольчастей (чтобы отрицать их особое значение).

В том же документе также указано:

Использование формата «пользователь:пароль» в поле userinfo устарело.

Соответственно, поддержка браузера была неоднородной, то появлялась, то исчезала в разных версиях (безопасность — главная проблема). Я считаю, что последние версии Chrome (протестировано v79) и Firefox поддерживают учетные данные пользователя в URL. Я видел комментарии, что это также работает в последней версии Safari(?), хотя это не работало долгое время и в настоящее время не работает у меня (хотя я не использую последнюю версию на iOS 12.4.1). ИIE прекратил поддержку имен пользователей и паролей в URLнесколько лет назад, и похоже, что это не вернется.

Связанный контент