Supposons que je souhaite télécharger automatiquement un fichier à partir d'une adresse URL située dans un site Web requis par l'authentification dans lequel je me connecte à l'aide du contrôle WebBrowser automatisé basé sur Internet Explorer. Mais, une fois que je suis là et que j'attrape le lien vers le fichier, si j'essaie de le télécharger directement via IE6 en naviguant dessus, il y aura le dialogue modal "voulez-vous ouvrir ou enregistrer ce fichier". Et si j'essaye de le télécharger en utilisant la classe C# WebClient, ça n'a pas fonctionné, tout ce qui a été téléchargé était un petit javascript non significatif. En fait, par curiosité, j'ai testé la méthode WebClient sur le site Gmail en essayant de télécharger des pièces jointes, et ça ne fonctionnait pas non plus (je sais que depuis Gmail je peux les récupérer via l'interface POP3, c'était juste une expérience). Eh bien, cela me pose des questions sur la mécanique sous-jacente de tout cela. Tout d'abord, peut-être que j'utilise WebClient dans le mauvais sens? Ou peut-être existe-t-il d'autres classes C# standard pour télécharger des fichiers dans de telles circonstances? Si ce n'est pas le cas, est-ce que l'application peut usurper le comportement du navigateur pour que le serveur pense que la demande de fichier en provient, même si elle provient d'une autre partie du même processus? Que fait exactement le navigateur dans cette situation qui lui permet de télécharger les fichiers alors que WebClient ne peut pas le faire?l'application peut-elle contenir le contrôle WebBrowser en téléchargeant automatiquement les fichiers en usurpant le comportement du navigateur?
Répondre
Cela avait généralement à voir avec les cookies, ou d'autres en-têtes de requêtes HTTP que votre navigateur envoie. Le serveur Web ne peut pas distinguer b/w un navigateur Web piloté par un humain, ou un «webclient» contrôlé par code, tant qu'ils envoient exactement les mêmes en-têtes. Dans une «session» d'authentification dirigée par un humain (entrer un nom d'utilisateur/mot de passe), des cookies sont généralement envoyés du serveur au navigateur, et vous continuez d'être connecté, car votre navigateur envoie ces cookies au serveur. lors de demandes consécutives. Par conséquent, si votre client Web peut envoyer (poster?) Correctement les informations d'identification et continuer à stocker et à renvoyer les cookies (et/ou les en-têtes "referrer"/"user-agent"), il ne doit pas tout différent (à la fin c'est juste la requête, et la chaîne de réponse de HTT-Protocol).
Il peut y avoir des gardes de sécurité dans le "contrôle" particulier que vous utilisez pour l'empêcher (ou l'API) d'être utilisé par des logiciels malveillants. "Un programme essaie d'envoyer des courriels en votre nom, êtes-vous sûr de vouloir autoriser cela?" prompt, et le retard de 5 secondes qui l'accompagne dans MS Outlook en est un exemple. Donc, si une API particulière que vous utilisez a ce genre d'invite/précaution, vous ne pouvez pas vous occuper totalement des choses en silence.
Si vous voulez comprendre la différence entre deux programmes réseau, vous devez regarder le trafic réseau. Utilisez Fiddler ou quelque chose de similaire pour voir ce que fait chaque programme, puis comparez les deux.
Une réponse tardive pour les futures références: 'URLDownloadToCacheFile' [peut être utilisé pour cela] (http://stackoverflow.com/a/19025793/1768303). – Noseratio