Soucis au niveau des type de tests effectués - Vérification API

Question

Soucis au niveau des type de tests effectués - Vérification API

DocRoms opened this issue 2 years ago · 13 comments

Ce ticket consiste à trouver un moyen, coté API, pour éviter de renvoyer des résultats positifs lorsque le navigateur renvoie une erreur de page non sécurisée, tout est axpliqué dans cette partie de la conversation :

Discussed in #140

^{Originally posted by DocRoms September 17, 2022}
Nous avons quelques soucis sur certains tests effectués.

Par exemple, sur la page http://comptoirdescotonniers.com/nouveautes : après avoir terminé la page s'est vue attribuée la première place, avec un poids de 0Mo, 3élements de DOM et 1 requête 😅 . Lorsque l'on se rend sur le site, on constate que ça n'est juste pas possible.

@vvatelot a investigué de son coté et à trouvé que le navigateur affichait un message d'erreur lorsque la page n'était pas "safe"

En analysant les headers , on peut constater que la page renvoie un Upgrade-Insecure-Requests : 1. la MDN explique l'intérêt de ce header ici. Il y a peut-être un truc à faire côté API pour renvoyer une erreur lorsque l'on a ce type de résultat, et ne pas fausser les statistiques que l'on a sur l'audit des autres sites.

Answer 1 · 2022-09-17T07:07:38.000Z

Cette Issue est en relation avec l'issue cnumr/ecoindex_scrap_python#22

Answer 2 · 2022-09-18T13:01:27.000Z

En creusant le sujet, il n'est pas possible de récupérer le status code de réponse de selenium simplement: https://stackoverflow.com/questions/5799228/how-to-get-status-code-by-using-selenium-py-python-code

2 solutions:

Faire un appel avec un client HTTP avant de lancer le selenium pour analyse complète. Cette appel avec un client HTTP permet de valider que le site répond correctement. Problème: Ce comportement peut il être détecter par les outils de détection de bots...?
Parser les log performances du webdriver et récupérer la réponse sur un Network.responseReceived de notre page. Problème: Si il y a une rédirection, l'url ne correspond pas à l'url initiale...

🤔 Je demande un avis externe ! 😄

Answer 3 · 2022-09-20T15:08:01.000Z

Votre avis @yaaax @DocRoms

Answer 4 · 2022-09-20T19:54:19.000Z

Ah mince, désolé de ma réponse tardive.

Alors de mon point de vue, et si on veut respecter les principes de l'éco-conception, on ne devrait pas faire une double requête pour récupérer le status de la réponse. Mais ensuite, si on a pas le choix ...

Ensuite, coté Parsing de logs, est-ce que l'on aurait pas la stackTrace Initiale, pour remonter sur l'URL source, ou un ID de stack ? On peut se caler un point tous les deux si tu veux me présenter ça. On trouvera peut-être une solution adéquat ?

Answer 5 · 2022-09-21T07:56:15.000Z

Petite précision technique importante: l'idée serait de faire une requête HEAD pour récupérer uniquement le code réponse ..

En fait je pense que ça se discute à plusieurs niveau:

niveau ux : tu t'attends à avoir la réponse la plus rapide possible. Sachant que si on analyse les logs, il faut lancer chrome, interroger le site, attendre la fin du scénario et ensuite analyser les trames. Bref, attendre jusqu'à 10 secondes pour qu'on te dise "le site est en erreur...".
en terme de ressources utilisées, je pense que lancer un navigateur Chrome, lancer une navigation etc est plus coûteux que de faire une requête HEAD...

Answer 6 · 2022-10-03T07:54:07.000Z

Je ne suis pas sûr de comprendre : la requête HEAD, c'est pour l'option "Faire un appel avec un client HTTP avant de lancer le selenium pour analyse complète" ?

Mes compétences restent limitées pour ce sujet.
Je lis quand même sur le lien stackoverflow :

Your answer is wrong. Stefan Matei's answer and Jarad's answer get the status code.
– Peilonrayz Apr 22, 2021 at 9:57

Answer 7 · 2022-10-03T09:48:56.000Z

Je ne suis pas sûr de comprendre : la requête HEAD, c'est pour l'option "Faire un appel avec un client HTTP avant de lancer le selenium pour analyse complète" ?

Oui, tu fais d'abord un HEAD qui est très light et censé être rapide. Ça permet de récupérer le code de retour : Si 200, on continue, sinon, on arrête tout de suite et on renvoie vite une erreur

Mes compétences restent limitées pour ce sujet. Je lis quand même sur le lien stackoverflow :

Your answer is wrong. Stefan Matei's answer and Jarad's answer get the status code.
– Peilonrayz Apr 22, 2021 at 9:57

Oui, on peut lire le code réponse dans les logs, mais donc ça veut dire que qoui qu'il arrive:

Il faut initialiser le chromedriver et lancer un chrome sur le serveur (donc lourd...)
Il faut attendre que le scenario soit fini pour récupérer les logs (~10sec)
Et là il faut bien lire le status code de la page appelée (cf problèmes évoqués concernant la redirection...)

Donc plus j'y réfléchis et plus je pense que la requête HEAD serait la meilleure solution (fail fast, moins de ressources...).

Answer 8 · 2022-10-03T11:31:45.000Z

Go pour la requête HEAD alors, ça me parait bien.

Answer 9 · 2022-10-27T16:36:29.000Z

Bon, après avoir fait plusieurs tests, l'option HEAD ne semble finalement pas possible.
Sur certains sites (notamment protégés par des dispositifs anti bot), le HEAD répond une 401 alors que l'analyse passe correctement... Donc, je vais me baser sur l'analyse des réponses réseaux dans la trame des logs. En récupérant la première réponse, on sait si la réponse est OK ou KO.

Les questions que je me pose :

Quels codes réponses sont OK ? Uniquement 200 ?
Que fait on dans le cas d'un code différent de 200 : On enregistre le résultat tout de même en indiquant le code réponse ? Ou on l'enregistre pas du tout et l'API renvoie une erreur en indiquant le code erreur de l'analyse...?

Answer 10 · 2022-10-28T13:01:19.000Z

Je ne suis pas sûr de tout comprendre, mais dans l'idée, il paraissait effectivement intéressant d'utiliser une requête HEAD plutôt que lancer la machine. N'y-a-t-il de moyen de configurer cette requête pour imiter un user-agent ? A moins que cela soit l'IP de la demande qui bloque ?

Pour les codes de retour, j'ai un doute : si je fais un curl url-redirigée.com --head, je peux obtenir un code 301, ce qui n'empêchera pas un code 200 derrière.

Answer 11 · 2022-10-28T19:02:02.000Z

Hello, oui, sur le papier la requête HEAD paraissait plus "light", mais je pense qu'elle ne reproduit pas assez fidèlement la navigation utilisateur. Ce que j'ai mis en place dans cette PR permet de gérer les pages en erreur mais aussi de s'assurer que le mimetype de la réponse est bien text/html.

Le problème du HEAD c'est qu'effectivement il faudrait simuler un user agent qui permet de bypasser les protections anti bot. Mais clairement, c'est plus complexe qu'un simple user agent et c'est pour ça que je me repose sur undetected-chromedriver...

Answer 12 · 2022-10-28T19:52:38.000Z

Voilà la réponse de l'API en cas d'erreur 401 sur la page analysée (l'API renvoit une 500):

{
  "detail": {
    "args": [
      {
        "status": 401,
        "message": "This page can not be analyzed because the response status code is not 200"
      }
    ],
    "exception": "ConnectionError",
    "message": null
  }
}

ça vous va ?

Answer 13 · 2022-11-03T10:47:52.000Z

L'API renverra finalement une erreur custom 521:

{
  "detail": {
    "status": 401,
    "message": "This page can not be analyzed because the response status code is not 200"
  }
}