J’aimerais réaliser l’audit de site d’un site en interne donc qui ne necessite pas de passer par le proxy.
Voici le lien : http://(...)reseau-local.dgfip/ or lorsque je veux effectuer un audit de site le formulaire m’affiche dans un bouton rouge Please enter a valid URL (ex: http(s)://example.com).
Comment je peux faire y a-t-il une configuration à faire ?
C’est effectivement une limitation du formulaire d’ajout d’un contrat de site
qui permet d’ajouter actuellement uniquement des TLD officiels (.com, .net, .job, .paris, …) et des adresses IP. Dans la prochaine release localhost sera aussi utilisable.
Arrives-tu à faire des audits de page
sur cette URL du réseau localhttp://(…).reseau-local.(…)/ ?
Dans ce cas, tu peux utiliser les audits de scénario en générant au préalable la liste des URL à crawler. Si tu choisi cette solution, nous pourrons d’aider trouver à un crawler et ensuite à passer d’un fichier plat (1 URL par ligne) à un fichier JSON valide.
Si cette URL du réseau local http://(…).reseau-local.(…)/ est aussi consultable via son adresse IP (mais ce n’est peut-être pas le cas), tu peux alors utiliser un contrat de site sur cette IP.
Il existe une autre solution via la DB mais je n’arrive pas
à reproduire l’environnement réseau adapté pour tester.
Si le site nécessite une authentification, tu ne pourra pas utiliser l’audit de site. Le code HTTP 403 retourné par le serveur du site est caractéristique du fait que le crawler ne passe pas l’authentification. La seule solution est donc l’audit de scénario.
Quel type d’authentification est utilisée ?
via une formulaire dans une page HTML (comme Asqatasun) ?
via une authentification HTTP (pop pup du navigateur) ? (cf image ci-dessous)
@vivileds, pourrais-tu nous en dire un peu plus sur les réglages que tu as fait
pour pouvoir réaliser cet audit de site ? à priori, sur un site nécessitant une authentification ? Tu as fait des modifs dans le asqatasun.conf ?
Pour l’audit de site interne j’ai remplacé dans les classes CreateUserFormValidator, CreateContractFormValidator et SignUpFormValidator, l’appel au constructeur du org.apache.commons.validator.routines.UrlValidator en ajoutant un RegexValidator comme ceci :
UrlValidator urlValidator = new UrlValidator(schemes, new RegexValidator(".*"), UrlValidator.ALLOW_2_SLASHES);
Ce contournement permet, dans la page de gestion des contrats, de valider n’importe quelle URL.
J’ai une contrainte réseau : pour accéder aux sites externes il faut passer par un proxy mais pour les sites internes il ne faut pas l’utiliser. Cela se résout via proxyExclusionUrl pour les audits de pages.
Mais pour les audits de site, le crawler effectue tout d’abord une requête au serveur DNS afin de savoir si l’hôte distant est atteignable. Cependant le serveur DNS interne ne retourne de réponse positive que pour les sites internes ce qui provoque une erreur de domaine non résolvable pour les sites externes.
J’ai donc investigué dans le code de heritrix pour en déduire que le bean fetchProcessors lancent des processors avant le fetchHttp.
Le processors preconditions transforme les URLs http / https en dns: si celles-ci n’ont pas été résolues puis le processors fetchDns envoie réellement une requête au serveur DNS.
Pour résoudre mon problème j’ai donc commenté les lignes faisant références à ces deux beans. Le premier bean actif de la liste est maintenant le fetchHttp :
<bean id="fetchProcessors" class="org.archive.modules.FetchChain">
<property name="processors">
<list>
<!-- recheck scope, if so enabled... -->
<!--<ref bean="preselector"/>-->
<!-- ...then verify or trigger prerequisite URIs fetched, allow crawling... -->
<!-- <ref bean="preconditions"/> -->
<!-- ...fetch if DNS URI... -->
<!-- <ref bean="fetchDns"/> -->
<!-- ...fetch if HTTP URI... -->
<ref bean="fetchHttp"/>
<!-- ...extract oulinks from HTTP headers... -->
<ref bean="extractorHttp"/>
<!-- ...extract oulinks from HTML content... -->
<ref bean="extractorHtml"/>
<!-- ...extract oulinks from CSS content... -->
<ref bean="extractorCss"/>
<!-- ...extract oulinks from Javascript content... -->
<!--ref bean="extractorJs"/-->
<!-- ...extract oulinks from Flash content... -->
<!--ref bean="extractorSwf"/-->
</list>
</property>
</bean>
Si je comprend bien, tu as fait des modifications dans le code source, compilé avec maven, installé le nouveau .war et relancé tomcat…
C’est possible de commiter ces modifications (1 commit par fonctionnalité) dans une branche sur ton fork Github ? Histoire de conserver ces modifications…
Tu as regardé l’option bypassUrlCheck dans asqatasun.conf pour le problème de requête au DNS avant de faire les modifications du code source ?
L’option bypassUrlCheck ne résoud pas le problème de requête DNS. Si je comprend bien cette option, cela désactive le check si l’url spécifié est atteignable au niveau de Asqatasun et non au niveau du Crawler. Cette option n’est pas utilisé dans le configuration du Crawler. Dans les fichiers Spring, je ne vois qu’une utilisation de la variable dans asqatasun-resources/src/main/resources/conf/context/beans-processor.xml qui l’injecte dans la classe org.asqatasun.util.http.HttpRequestHandler or cette classe n’est pas utilisé par le Crawler si je ne me trompe pas.