Depuis hier, c'est le délire total sur un site intranet sur lequel je travail.
 
Je ne sais pas si je dois poster ça ici ou dans réseau. Par expérience dans réseau, j'ai rarementin eu des réponses (désolé par avance si ça choque des inconditionnels de cette cat ), et vu que c'est moitié programmation moitié réseau, je préfère poster ici.
 
Que fait le site.
Depuis le site, on génère un fichier WORD, qu'on transfère ensuite (côté serveur) sur un serveur FTP différent, qui est sur le réseau intranet lui aussi.
Ensuite, via un historique dans une base de données, on affiche une liste des documents générés, avec un lien vers les documents sous la forme :
 

 
OK. Jusque là tout va bien.
 
Seulement, lors des tests, on s'est apperçu que ça ne marchait pas. Encore mieu, la nouvelle fenêtre IE pointait sur "ftp://garlic/interface/crm/template/mondcument.doc", sans le mot de passe !
 
On a trouvé une astuce, bien porc, qui consiste à créer une iframe dans la page principale, pointant sur le répertoire FTP et non sur le fichier.
Grace à ça, pour une raison qui nous était inconnue, les liens marchait subitement.
 
Mais ça c'était jusqu'à hier...
Dans l'entreprise, tout le monde à grossomodo les mêmes machines (des Dell Optiplex) avec deux masters similaire :
- Windows 2000 Pro SP2
- Office 2000 Standard SR-1 ou SP2
- Internet Explorer 5.5 SP2
 
Et hier, y'a eu un nouvel arrivage de PC... Et c'est plus le même master...
Win2K SP4
Office 2000 SP3
IE n'a pas changé
 
Pour le reste, je ne sais pas, c'est un peu bizarre, parcequ'entre deux machines faites avec le même master, y'a pas les mêmes patches de sécurité
 
Enfin bref... Avec ces nouveaux PC, la iframe donne une page 404, et du coup les liens ne marchent plus.
 
J'ai bidouillé pendant deux demi-journées sur un de ces nouveaux PC, et après avoir réinstallé 3 versions différentes d'Office 2000 (à partir de master, vous avez déjà fait une install d'un produit M$ en faisant des copier/coller de fichier et en faisant tourner des *.reg ? et j'ai fini par faire marche.
 
Sur une autre machine, j'ai été incapable de reproduire le résultat, du coup je n'ai pas de "white paper" à proposer aux utilisateurs de ces nouvelles machines pour accéder au site.
 
Alors que je faisais des tests, mon SmartFtp a eu la bonne idée de démarrer une connection FTP alors que je faisais un copier/coller de l'url FTP du site. (merci merci merci SmartFTP )
 
L'url était :
ftp://login:passe@garlic/interface/crm/template/
 
Et ça a donné ça :
 

 
Je crois que là, j'ai trouvé la raison du pourquoi du comment : le mot de passe dans l'url est intercepté par le proxy (y'a plein de sous-réseau ici, et des proxy un peu partout, ce proxy n'est pas le proxy internet, je ne sais pas d'où il sort)
 
Pour une raison inconnue, avec l'ancien master, IE indique au proxy que le mot de passe n'est pas pour lui. Et à priori, comme SmartFTP vient de le faire, le nouveau master file le mot de passe au proxy au lieu de s'y connecter en anonyme.
 
Dans SmartFTP, si je met "garlic" comme nom de serveur avec le login/pass dans les champs spécifiques, la connection se fait correctement par contre.
 
Bref. J'ai l'impression que le souci vient directement de cette syntaxe d'url...
 
Alors la question (et oui, vous l'attendiez tous ) c'est :
 
Quelle modification dois-je apporter à cette url pour que le proxy ne prenne plus la main sur le mot de passe ?
 

Tu as dis que IE etait la meme version ? Hmmm bizzare, a moins que ...
 
Je me souviens d'un correctif de securite pour IE, il corrigeait une faille en relation avec les adresses du type : [prot]://[login]:[motdepasse]@[server]
Microsoft avait eu la bonne idee, d'enlever tout le support de ces liens au lieu de corriger la faille ...
Donc il se peut que sur un pc ce correctif soit installe, donc du coup les adresses du type : ftp://user:motdepasse@server  
ne fonctionnent plus.
Et sur une autre machine que ce correctif n'y soit pas et que l'url fonctionne ...
 
Sinon, essaye de voir si tu as le meme proxy ds les parametres de connections des 2 pc. Si c'est le cas, tu pourrais eventuellement ajouter ton serveur ftp ds la liste des "ne pas utiliser le proxy pour ces adresses ci" (a condition que ton serveur soit accessible directement sans passer par le proxy).
 
Dernier test que tu peux faire, essaye avec FireFox. En effet ce dernier a encore le support vers les adresses qui ont le login et mot de passe ds l'url.
 
Enfin voila, j'espere avoir pu t'aider.

Pour ce qui est du proxy, oui, c'est bien le même. J'ai modifié sur tous les PC avec celui que j'utilise (c'est un peu le bordel ici, y'a au moins 5 proxy différents selon l'habilitation des gens )
 
Mais ça ne change rien.
 
Pour les failles de sécu, sans connaître le détail, j'avais souvenir d'un truc du genre, et j'ai donc tenté de voir de ce côté. Seulement, en comparant des PC qui marchaient avec des PC qui ne marchaient pas, on a fini par déduire que la seule différence entre "mache/mache pas" était Office 2000 SP3 (il doit contenir ce correctif). Seulement, vu que c'est des master à la con... (vous avez déjà réussi à installer à la fois, sur le même pc, des drivers nVidia, Intel et ATI pour la carte graphique vous ? Ben ici, oui )
J'ai eu beau supprimer Office et tenter de réinstaller la SR-1, à chaque fois il me remet la version SP3 dans la tête
 
Sinon, on a fini par résoudre le problème d'une façon peu orthodoxe, mais qui semble fonctionner...
Au lieu de stocker les fichier sur un FTP distinct, on les met sur le serveur IIS. Vu que lorsque le PC se conencte à IIS, il sait comment y accéder, ça ne pose plus de problème pour s'y connecter en FTP dans la même session
 
Super, j'ai dû réécrire la moitié des macros et autres pages du site permettant d'accéder/modifier les fichiers