Использование cURL с именем пользователя и паролем? - PullRequest
Новая
       40

Использование cURL с именем пользователя и паролем?

396 голосов
/ 07 апреля 2010

Я хочу получить доступ к URL, который требует имя пользователя / пароль.Я хотел бы попробовать получить к нему доступ с помощью curl.Сейчас я делаю что-то вроде: 

curl http://api.somesite.com/test/blah?something=123

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

Как я могу это сделать?

Ответы [ 15 ]

3 голосов
/ 24 июля 2018

Другие ответы предложили netrc указать имя пользователя и пароль, основываясь на том, что я прочитал, я согласен. Вот некоторые детали синтаксиса:

https://ec.haxx.se/usingcurl-netrc.html

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

Хотя я не эксперт, я нашел эти ссылки проницательными:

https://ec.haxx.se/cmdline-passwords.html

Подведем итог:

Использование зашифрованных версий протоколов (HTTPS против HTTP) (FTPS против FTP) может помочь избежать утечки в сети.

Использование netrc может помочь избежать утечки командной строки.

Чтобы пойти дальше, кажется, вы также можете зашифровать файлы netrc с помощью gpg

https://brandur.org/fragments/gpg-curl

При этом ваши учетные данные не «в состоянии покоя» (хранятся) как обычный текст.

3 голосов
/ 07 мая 2017

Вы можете использовать команду, как, 

curl -u user-name -p http://www.example.com/path-to-file/file-name.ext > new-file-name.ext

Тогда будет активирован пароль HTTP.

Ссылка: http://www.asempt.com/article/how-use-curl-http-password-protected-site

3 голосов
/ 16 февраля 2016

Если вы работаете в системе, в которой есть приложение для набора ключей Gnome, решение, которое позволяет не раскрывать пароль напрямую, заключается в использовании gkeyring.py для извлечения пароля из набора ключей: 

server=server.example.com
file=path/to/my/file
user=my_user_name
pass=$(gkeyring.py -k login -tnetwork -p user=$user,server=$server -1)

curl -u $user:$pass ftps://$server/$file -O
2 голосов
/ 16 октября 2017

У меня была такая же потребность в bash (Ubuntu 16.04 LTS), и команды, приведенные в ответах, не работали в моем случае. Я должен был использовать: 

curl -X POST -F 'username="$USER"' -F 'password="$PASS"' "http://api.somesite.com/test/blah?something=123"

Двойные кавычки в аргументах -F нужны только в том случае, если вы используете переменные, поэтому из командной строки ... -F 'username=myuser' ... будет хорошо.

Я был бы рад, если бы комментарий или правка могли объяснить почему!

1 голос
/ 14 мая 2019

Самый безопасный способ передачи учетных данных в curl - это ввести их. Это то, что происходит при передаче имени пользователя, как предлагалось ранее (-u USERNAME).

Но что, если вы не можете передать имя пользователя таким образом? Например, имя пользователя может быть частью URL-адреса, и только пароль должен быть частью полезной нагрузки json.

ТЛ; др: Вот как безопасно использовать curl в этом случае: 

read -p "Username: " U; read -sp "Password: " P; curl --request POST -d "{\"password\":\"${P}\"}" https://example.com/login/${U}; unset P U

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

Я расскажу, почему другие решения не идеальны.

Почему переменные среды небезопасны

  1. Режим доступа и доступа к содержимому переменной среды не может отслеживаться (ps -eww), поскольку среда неявно доступна для процесса
  2. Часто приложения захватывают всю среду и регистрируют ее для целей отладки или мониторинга (иногда в виде текстовых файлов на диске, особенно после сбоя приложения)
  3. Переменные среды передаются дочерним процессам (следовательно, нарушается принцип наименьших привилегий)
  4. Поддержание их является проблемой: новые инженеры не знают, что они там есть, и не знают о требованиях вокруг них - например, не передавать их подпроцессам - поскольку они не применяются или не документированы. *

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

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

Страница:
...