Le client a résolu, avec un problème que son collecteur ne peut pas faire face à la protection "incapsula".
En un mot, au lieu du code de la page, un code javascript est renvoyé, une fois exécuté, une demande est faite aux encapsulations du serveur, certains paramètres du navigateur sont vérifiés, et si le navigateur est reconnu comme valide, la page et certains cookies sont renvoyés .
Une description détaillée se trouve sur le site Web du développeur (www.imperva.com)
L'ajout d'un processeur javascript, ainsi que d'autres solutions proposées par Google (par exemple, surélever vos serveurs), m'a paru trop compliqué / long. Selenium, il s'est avéré, contourne parfaitement cette protection, mais comme il y a beaucoup de données et de collecte dans un flux, (ou même de basculer entre les onglets), je ne voulais pas, et il n'y avait pas assez de ressources pour lancer plusieurs navigateurs , il a été décidé d'écrire un serveur proxy.
Étant donné que la charge a changé, en fonction de l'heure de la journée et d'autres conditions, il a été décidé de créer un composant WebPart évolutif en combinant Nginx + uwsgi + flask. Il semblait trop coûteux d'exécuter la version Selenium pour chaque travailleur, il a donc été décidé de déplacer Selenium dans un service séparé, avec une communication entre les blocs via Redis. Pour que l'implémentation reste aussi simple que possible, les requêtes sont exécutées de manière synchrone.
Structure du projet
uwsgi.ini – . , . (
selenium:
gecko/Sel.py
sellenium . , selenium , ( ). cookie Redis. Cookie , redis. cookie callback .
API:
src
, 1 url:
@app.route('/', methods=['GET', 'POST'])
, url url, , post .
:
http://127.0.0.1:5000/?url=https://www.example.com/vehicledetails/34313441?RowNumber=0&
, , , .
request.py .
requests, .
Redis, Post, Get c reqests.
, cookie, Selenium .
, . https, , , . . , .