Qu’est ce que tu as observé exactement comme blocage sur ta seconde requête ?
Je recois un recaptcha (https://www.google.com/recaptcha/api2/). Pourtant j’ai set Useragent valide / header language / header encododing.
A chaque changement d’IP ca remarche, mais je pense qu’il y a moyen de faire plusieurs requêtes sur la même IP.
Est-ce que tu peux me filer le lien / URL de la page en question ?
A vrai dire depuis mon poste en local tout fonctionne plusieurs fois, mais dès que je publie sur mon hébergeur node (Heroku) le deuxième call reçoit un recaptcha. Du coup je ne vois pas bien ou est la diff …
Quel est le résultat si tu ouvres cette page depuis ton puppeteer en local:
1 « J'aime »
Alors j’ai beau me battre impossible de charger la page https://arh.antoinevastel.com/bots/areyouheadless avec Pupetters ( Navigation failed because browser has disconnected!), ou est le piège ?
Pourtant avec un simple Fetch je récupère le dom et passe le test (You are not headless)
Si tu as un « Navigation failed because browser has disconnected! » c’est car tu fermes le headless browser bien trop tôt, avec un browser.close(), ou du moins que ce dernier a été fermé involontairement avant la fin du processus.
Il ne faut pas oublier un des principes de base en JavaScript + Nodejs: on est en asynchrone, et suffit qu’on oublie un mot-clé « await » devant une ligne « browser.close() » pour que cette ligne soit exécutée avant les autres… Ca arrive souvent par erreur.
En tout cas, ton problème provient d’une erreur de codage, mais en aucun cas il ne s’agit d’un bug du site ciblé 
Merci de tes réponses rapides. C’est ce qui semble ressortir des différents forums en effet.
Le problème ne venait pas d’un await manquant, mais de l’arg « –single-process ».
Sans celui-ci, j’arrive à appeler le site areyouheadless, mais je me fais détecter vu que la réponse est « You are Chrome headless »
Là je t’avoue ne pas comprendre, on n’utilise jamais le param single-process, en tout cas ce dernier n’est en rien responsable de la détection ou non détection du headless browser.
Le but du test de ton headless browser sur la page https://arh.antoinevastel.com/bots/areyouheadless est de vérifier si l’empreinte numérique que laisse ton browser est catégorisée en tant que bot ou humain, et dans ton cas cela prouve que tu laisses « trop de traces » qui suggèrent que tu utilises un headless browser et non pas un véritable navigateur, il te faut donc masquer un maximum de l’ADN de ton headless browser…
single-process permet de limiter la mémoire que va prendre le browser, effectivement il ne joue pas sur la détection du headless ou non, mais le fait qu’il soit présent faisait crasher puppeteers quand j’appelais cette page spécifique.
Dans tous les cas merci, il faut que je masque mon ADN ! Set un user agent ne semble pas suffire.
Hélas, non.
Ce qui peut définir l’ADN d’un navigateur, entre autre:
- User-agent
- Résolution et taille écran
- Plugins utilisés
- Carte graphique (signature constructeur et modèle)
- …, et j’en passe…
J’ai finalement passé le test areyouheadless en local et sur Heroku, pourtant à partir de la 2ème requête SeLoger me renvoi un captcha sur Heroku alors que tout marche en local plusieurs fois.
Est-ce que l’IP utilisée en local et sur Heroku est la même (utilisation d’un proxy) ou bien est ce que l’IP utilisée en locale t’es propre, et est différente de celle utilisée sur Heroku ?
D’autre part, il est possible que la version de Puppeteer déployée sur Heroku laisse des traces spécifiques, qu’on ne retrouve pas nous en local.
L’IP est différente en Local / Heroku, du coup vu que le premier call est OK, ça pourrait venir de la version de Puppeteer comme tu dis.
Certaines version de Puppeteer peuvent laisser plus de traces que d’autres ?
Peut être que c’est l’environnement de son serveur qui est détecté.
Non c’est tout headless browser , indépendamment de sa version, ils laissent tous des tonnes de traces.
Ok, mais dans ce cas il aurai la même erreur en local ou sur serveur.
J’ai finalement mis en place une rotation d’ip avec des proxys. Je pense que c’était la plage d’ip de mon serveur qui était « black list ».
2 « J'aime »
Merci de ton retour. Malheureusement il y a énormément de plages de providers de proxys qui sont dores et déjà bien grillées…
Il semblerait que seloger a changé son API. Il faut désormais effectuer un POST
- adresse de l’API : https://seloger.com/list/api/externaldata?from=0&size=25&isSeo=false avec des paramètres du type
- payload example: {« enterprise »:false,« projects »:[2,5],« natures »:[1,2,4],« types »:[1,2],« places »:[{« label »:« Paris »,« dpCode »:[« 75 »]}],« rooms »:[1,2,3,4,5]}
J’ai essayé ca en python mais j’ai l’impression que cela me renvoit un résultat crypté. Vous avez des idées ?
API_ENDPOINT = « https://seloger.com/list/api/externaldata?from=0&size=25&isSeo=false »
data = {« enterprise »:« false »,« projects »:[2,5],« natures »:[1,2,4],« types »:[1,2],« places »:[{« label »:« Paris »,« dpCode »:[« 75 »]}],« rooms »:[1,2,3,4,5]}
r = requests.post(API_ENDPOINT, data=json.dumps(data))