# [WGET] --http-user non pris en compte

## gregool

Bonjour,

il m'arrive un truc pour le moins étrange.

j'ai 2 stations chez moi, une sous Debian une sous Gentoo.

je télécharge souvent des fichiers venant de rapidshare.com, des vidéos de concert pour une asso, c'est pas tres volumineux mais ça peut etre par exemple 8 morceaux de vidéos et j'en fais un montage bref...

j'ai donc un compte premium pour pas mettre 2 jours a tout récupérer.

pour faire ça j'utilise wget de la façon suivante:

wget --http-user=monuser --http-password=monpasswd --input-file=list.txt

et dans la liste je met les fichiers dont j'ai besoin, si c'est un seul fichier je met juste l'url.

bon et bien de Debian ça fonctionne sans aucun pb, sous gentoo ça ne marche pas.

le user et le mot de passe ne sont pas pris en compte !?

il me telecharge des fichier de 1ko, quand je fais le test sans mettre --http-user ça fait pareil, et de Debian qd je ne mets pas --http-user j'ai aussi la meme chose, c'est ce qui me laisse penser que le user n'est pas pris en compte.

j'utilise wget 1.11.3, j'ai bien openssl d'installé, j'ai compilé wget avec tout les use flags de dispo, qu'est ce qui pourrait coincer?

merci de votre aide   :Smile: 

----------

## gregool

Bon je progresse un peu dans les investigations.

je dois avoir un pb d'authentification, c'est soit du Basic soit du DIGEST soit du NTLM

j'ai ajouté les USE FLAGS: auth_basci auth_digest et auth_ntlm a mon make.conf, j'ai fais un emerge -uDN world, ça m'a re emerger des choses genre openssl, je pensais toucher au but mais pour l'instant toujours pas...

je suis preneur si qqun a une piste

merci les gars

----------

## GentooUser@Clubic

Déjà  auth_basci, auth_digest et auth_ntlm ne semblent pas être des useflags existants (en tout cas ils n'ont pas d'entrée dans use.desc)

Ensuite puisque tu as emergé wget avec tous les usesflags essai de lancer wget avec l'option --debug pour avoir plus d'infos

----------

## boozo

 *GentooUser@Clubic wrote:*   

> Déjà  auth_basci, auth_digest et auth_ntlm ne semblent pas être des useflags existants (en tout cas ils n'ont pas d'entrée dans use.desc)
> 
> Ensuite puisque tu as emergé wget avec tous les usesflags essai de lancer wget avec l'option --debug pour avoir plus d'infos

 

En effet c'est pour les modules apache çà

Je regarderai plutôt du côté de --no-check-certificate si tu veux tester pour voir mais qu'en est-il de la version de wget sous deb ? (puisque cette cmdline fonctionne avec)

Sinon juste pour info, tu devrais passer via le wgetrc pour coller tes userid et passwd - c'est un peu plus "propre" ^^

Et pis pour la route - et optimiser ton oneliner - jette un oeil au très complet : 

```
$info wget
```

----------

## gregool

merci pour les infos, sous Debian c'est la version 1.10.2 de Wget.

j'ai essayé avec d'autre distrib que j'avais sous la main genre ubuntu et red hat, et ça fonctionne aussi.

je suis sur que ça doit etre un grain de sable qui m'empeche de me signer sur le serveur d'en face.

et oui effectivement je n'utilise pas la methode la plus sure ni la plus propre je veux juste arriver à ce que ça fonctionne et ensuite je vais optimiser la procédure.

j'essaie de lister les paquet installés des 2 cotés en espérant trouver ce qui peut me manquer.

----------

## gregool

bon avec --no-check-certificate ça ne marche pas non plus.

si je fais un spider j'ai bien la bonne taille du fichier mais si je le dl j'ai un fichier de 1Ko :

```
Vesta Download # wget --spider --no-check-certificate --http-user=123456 --http-password=654321 http://rapidshare.com/files/128123202/os-unix-i-linux.rar

Spider mode enabled. Check if remote file exists.

--2008-07-10 20:45:20--  http://rapidshare.com/files/128123202/os-unix-i-linux.rar

Résolution de rapidshare.com... 195.122.131.20, 195.122.131.9, 195.122.131.11, ...

Connexion vers rapidshare.com|195.122.131.20|:80...connecté.

requête HTTP transmise, en attente de la réponse...200 OK

Longueur: 2293622 (2,2M) [application/octet-stream]

Remote file exists.

Vesta Download # wget --no-check-certificate --http-user=123456 --http-password=654321 http://rapidshare.com/files/128123202/os-unix-i-linux.rar

--2008-07-10 20:45:35--  http://rapidshare.com/files/128123202/os-unix-i-linux.rar

Résolution de rapidshare.com... 195.122.131.17, 195.122.131.2, 195.122.131.6, ...

Connexion vers rapidshare.com|195.122.131.17|:80...connecté.

requête HTTP transmise, en attente de la réponse...200 OK

Longueur: 8879 (8,7K) [text/html]

Saving to: `os-unix-i-linux.rar'

100%[======================================>] 8.879       --.-K/s   in 0,08s   

2008-07-10 20:45:35 (113 KB/s) - « os-unix-i-linux.rar » sauvegardé [8879/8879]

```

à priori sur ce que j'ai pu lire l'authentification c'est du Basic.

c'est dingue quand meme

----------

## boozo

oui... étrange en effet 

Es-tu sûr de ne pas télécharger un "lien" en fait ? as-tu essayé avec --retr-symlinks ?

Sinon côté bibliothèques pour wget : je pense que si ssl était en cause tu le saurais direct et d'une façon plus claire dans les logs ou dans l'output mais sait-on jamais : tu as bien refait les liens quivontbien lors du dernier update d'openssl i.e. revdep-rebuild -X <libssl.so.x.x.x> - s'il y en avait - ?

Pour le mode spider et la différence de taille (2.2M->8.7K) je ne sais pas trop... est-ce fiable ce mode pour une comparaison ?

----------

## GentooUser@Clubic

Ta regardé ce que contient le fichier téléchargé ?

C'est peut-être une page html d'erreur.

Regarde aussi le fichier /etc/wgetrc de debian et gentoo, si y'a des différences .

----------

## gregool

bon bon bon, 

je continue a chercher.

donc les fichier wgetrc sont identiques sur les 2 OS.

quand je telecharge un fichier il arrive avec la meme extension que le vrai fichier.

genre je veux manlinux.rar, j'ai un rar de 3ko impossible a ouvrir, mais !

si je RE telecharge le meme fichier au meme endroit alors j'ai un manlinux.rar.1

et la je peux ouvrir, c'est bien une page HTML, une page qui me demande si je suis un user free ou premium !

donc c'est bel et bien un pb d'authentification, je ne pas me signer.

et l'option --retr-symlinks n'a pas corrigé le tir non plus.

je troune en rond, malgré tout j'ai reussi faute de regler le pb a le contourner en telechargeant avec Downthemall mais c'est tiré par les cheveux...

merci pour votre aide en tout cas !

je continue a chercher

----------

## GentooUser@Clubic

Ça résout pas le problème mais tu as essayé avec curl ?

----------

## gregool

alors,

deja merci pour vitre aide tout seul c'est pas facile  :Smile: 

donc non je n'ai pas testé avec curl, je n'utilise jamais curl, j'ai le reflexe wget qd je veux dl quelquechose.

mais je vais faire l'essai pour voir, si ça marche avec Curl ça m'ira très bien.

alors j'ai avancé de façon significative, le pb de --http-user n'est pas résolu mais malgré tout j'arrive a telecharger en passant par WGET.

et finallement cette methode est peut etre encore mieux.

jusque la je passais par downthemall puisque wget ne marchait plus, pour ce faire je devais me connecter a mon compte premium et laisser la page ouverte pour profiter du cookie encore présent dans Firefox.

donc je me suis inspiré de cette méthode pour utiliser Wget,

j'ai sauvegardé le cookie, et au  lieu de d'utiliser http-user je charge le cookie en utilisant --load-cookies.

et la ça passe.

ça me parrait même plus sécurisé, vous en pensez quoi?

----------

