C# WebClient - Voir la question source

Question

J'utilise un C# WebClient pour publier les informations de connexion à une page et lire tous les résultats.

La page que j'essaye de charger inclut le flash (qui, dans le navigateur, traduit en HTML). Je suppose que c'est flash pour éviter d'être ramassé par les moteurs de recherche ???

Le flash qui m'intéresse est juste du texte (pas une image/vidéo) etc et quand je "View Selection Source" dans firefox je vois effectivement le texte, en HTML, que je veux voir.

(Fait intéressant quand je considère la source de la page entière, je ne vois pas le texte, dans HTML, que je veux voir. Cela pourrait-il être lié?)

Actuellement après avoir posté mes identifiants, et chargé le HTML en arrière, je vois la page qui n'affiche pas le flash HTML (comme si j'avais vu la source pour toute la page).

Merci à l'avance,

Jim

PS: Je tiens à souligner que le POST fonctionne réellement, mon journal en est réussie.

Answer 1

(ou un outil similaire) est inestimable pour dépister les problèmes de grattage d'écran comme celui-ci. En utilisant un navigateur normal et avec fiddler actif, regardez toutes les demandes faites pendant que vous passez par le processus de connexion et de navigation pour obtenir les données que vous voulez. Entre les deux, vous verrez probablement une ou plusieurs choses que votre code fait différemment auxquelles le serveur répond et donc vous montreront du HTML différent d'un vrai client.

La liste des choses ci-dessous (pensez à "scraping 101") est ce que vous voulez rechercher. La plupart des choses ci-dessous sont probablement des choses que vous faites déjà, mais j'ai inclus tout pour être complet.

Afin de gratter efficacement, vous devrez peut-être traiter avec un ou plusieurs des éléments suivants:

1. cookies et/ou des champs cachés. lorsque vous vous présentez sur une page d'un site, vous obtenez généralement un cookie de session et/ou un champ de formulaire caché qui (dans un navigateur normal) serait propagé au serveur lors de toutes les demandes suivantes. Vous aurez probablement aussi un cookie persistant. Sur de nombreux sites, si une requête apparaît sans cookie (ou champ de formulaire pour les sites utilisant des "sessions sans cookie"), le site redirigera l'utilisateur vers une interface utilisateur "pas de cookies", une page de connexion ou un autre emplacement indésirable. la perspective de l'application scraper). assurez-vous toujours de capturer les cookies réglés sur la demande initiale et renvoyez-les fidèlement au serveur lors des requêtes suivantes, sauf si l'une de ces requêtes suivantes modifie un cookie (dans ce cas, propagez plutôt ce nouveau cookie).
2. jetons d'authentification un cas particulier de ce qui précède est des cookies d'authentification par formulaires ou des champs masqués. assurez-vous de capturer le jeton de connexion (généralement un cookie) et de le renvoyer.
3. POST vs GET cela est évident, mais assurez-vous que vous utilisez la même méthode HTTP qu'un vrai navigateur.
4. champs de formulaire (en particulier. Ceux qui sont cachés!) Je suis sûr que vous faites déjà, mais assurez-vous d'envoyer tous les champs de formulaire qu'un vrai navigateur ne, pas seulement les champs visibles. Assurez-vous que les champs sont codés en HTML correctement.
5. En-têtes HTTP. vous avez déjà vérifié cela, mais il peut être utile de vérifier à nouveau juste pour s'assurer que les en-têtes (non-cookie) sont identiques. Je commence toujours par exactement les mêmes en-têtes, puis je commence à sortir les en-têtes un par un, et ne conserve que ceux qui provoquent l'échec de la requête ou retournent des données fausses. cette approche simplifie votre code de grattage.
6. redirections. Ceux-ci peuvent provenir du serveur ou du script client (par exemple, si l'utilisateur n'a pas de plug-in Flash chargé, rediriger vers une page non-flash). Voir WebRequest: How to find a postal code using a WebRequest against this ContentType="application/xhtml+xml, text/xml, text/html; charset=utf-8"? pour un exemple fou de la façon dont la redirection peut déclencher un scraper d'écran. Notez que si vous utilisez .NET pour le scraping, vous devez utiliser HttpWebRequest (et non WebClient) pour le scraping dépendant de la redirection, car par défaut WebClient ne permet pas à votre code de joindre des cookies et des en-têtes à la seconde. demande (post-redirection). Voir le fil ci-dessus pour plus de détails.
7. Sous-requêtes (cadres, ajax, flash, etc.) - souvent, les éléments de page (et non les requêtes HTTP principales) finiront par récupérer les données que vous voulez récupérer. vous serez en mesure de comprendre cela en regardant quelle réponse HTTP contient le texte que vous voulez, puis en travaillant à rebours jusqu'à ce que vous trouviez ce qui sur la page fait réellement la demande pour ce contenu. Quelques sites font des choses vraiment dingues dans les sous-requêtes, comme demander un texte compressé ou crypté via ajax, puis utiliser un script côté client pour le déchiffrer. Si tel est le cas, vous devrez faire un peu plus de travail comme l'ingénierie inverse de ce que fait le script client.
8. ordering - ceci est évident: faites des requêtes HTTP dans le même ordre qu'un client naviguant. cela ne signifie pas que vous devez faire chaque demande (par exemple, des images). Généralement, vous n'avez besoin que de faire les demandes qui renvoient le type de contenu text/html, à moins que les données que vous voulez ne soient pas dans le HTML et soient dans un ajax/flash/etc. demande.

Answer 2

(Fait intéressant quand je considère la source de la page entière, je ne vois pas le texte, dans HTML, que je veux voir. Cela pourrait-il être lié?)

Ce généralement moyen que la divergence est causée par certaines manipulations DOM via javascript après le chargement de la page. Essayez de désactiver le javascript et de voir à quoi il ressemble.