Utilisation de cURL avec un nom d'utilisateur et un mot de passe ?

Question

Je veux accéder à une URL qui nécessite un nom d'utilisateur / mot de passe. J'aimerais essayer d'y accéder avec curl. En ce moment, je fais quelque chose comme :

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

Je reçois une erreur. Je suppose que je dois spécifier un nom d'utilisateur et un mot de passe avec la commande ci-dessus.

Comment puis-je faire cela ?

Answer 1

J'avais le même besoin en bash (Ubuntu 16.04 LTS) et les commandes fournies dans les réponses n'ont pas fonctionné dans mon cas. J'ai dû utiliser :

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

Les guillemets doubles dans les arguments -F sont nécessaires uniquement si vous utilisez des variables, donc à partir de la ligne de commande ... -F 'username=myuser' ... sera suffisant.

Avis de sécurité pertinent : comme M. Mark Ribau le souligne dans les commentaires, cette commande affiche le mot de passe (variable $PASS, étendue) dans la liste des processus !

Answer 2

Vous pouvez utiliser une commande comme suit,

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

Ensuite, le mot de passe HTTP sera demandé.

Référence: http://www.asempt.com/article/how-use-curl-http-password-protected-site

Answer 3

La manière la plus sûre de transmettre des informations d'identification à curl est d'être invité à les insérer. C'est ce qui se passe lorsque vous transmettez le nom d'utilisateur comme suggéré précédemment (-u NOM_UTILISATEUR).

Mais que se passe-t-il si vous ne pouvez pas transmettre le nom d'utilisateur de cette manière? Par exemple, le nom d'utilisateur pourrait avoir besoin de faire partie de l'URL et seul le mot de passe de faire partie d'une charge utile json.

tl;dr: Voici comment utiliser curl en toute sécurité dans ce cas:

read -p "Nom d'utilisateur : " U; read -sp "Mot de passe : " P; curl --request POST -d "{\"password\":\"${P}\"}" https://exemple.com/login/${U}; unset P U

read demandera à la fois le nom d'utilisateur et le mot de passe à partir de la ligne de commande, et stockera les valeurs soumises dans deux variables qui peuvent être référencées dans les commandes ultérieures et enfin supprimées.

Je vais expliquer pourquoi les autres solutions ne sont pas idéales.

Pourquoi les variables d'environnement ne sont-elles pas sûres

1. La manière d'accéder et la modalité d'exposition du contenu d'une variable d'environnement ne peuvent pas être suivies (ps -eww) car l'environnement est implicitement disponible pour un processus.
2. Les applications récupèrent souvent l'intégralité de l'environnement et le journalisent à des fins de débogage ou de surveillance (parfois dans des fichiers journaux en texte clair sur le disque, notamment après un crash d'application).
3. Les variables d'environnement sont transmises aux processus enfants (ce qui va à l'encontre du principe du moindre privilège).
4. Les maintenir pose un problème : les nouveaux ingénieurs ne savent pas qu'elles existent et ne sont pas au courant des exigences les entourant - par exemple, de ne pas les transmettre aux sous-processus - car elles ne sont pas appliquées ou documentées.

Pourquoi est-il dangereux de le taper directement dans une commande en ligne de commande Parce que votre secret finit alors par être visible par tout autre utilisateur exécutant ps -aux puisque cela liste les commandes soumises pour chaque processus en cours d'exécution. Aussi parce que votre secret finit par figurer dans l'historique de bash (une fois que le shell se termine).

Pourquoi est-il dangereux de l'inclure dans un fichier local Les restrictions d'accès strictes POSIX sur le fichier peuvent atténuer le risque dans ce scénario. Cependant, c'est toujours un fichier sur votre système de fichiers, non chiffré au repos.

Answer 4

Tout simplement, la manière la plus sécurisée serait d'utiliser des variables d'environnement pour stocker/récupérer vos identifiants. Ainsi, une commande curl comme :

curl -Lk -XGET -u "${API_USER}:${API_HASH}" -b cookies.txt -c cookies.txt -- "http://api.somesite.com/test/blah?something=123"

Appellerait alors votre API restful et transmettrait l'en-tête http WWW_Authentication avec les valeurs encodées en Base64 de API_USER et API_HASH. Le -Lk indique simplement à curl de suivre les redirections 30x http et d'utiliser une gestion tls non sécurisée (c'est-à-dire d'ignorer les erreurs ssl). Les doubles -- sont simplement du sucre syntaxique bash pour arrêter le traitement des drapeaux de ligne de commande. De plus, les drapeaux -b cookies.txt et -c cookies.txt gèrent les cookies avec -b envoyant les cookies et -c les stockant localement.

Le manuel contient d'autres exemples de méthodes d'authentification.

Answer 5

Dans certaines API, cela ne fonctionne peut-être pas (comme rabbitmq).

Il existe une alternative :

curl http://username:password@example.com

curl http://admin:123456@example.com

aussi le format ci-dessus peut être utilisé dans les navigateurs.