Car quel est le dossier «bien connu»?

Si vous avez trouvé un nouveau message d'erreur dans nos fichiers journaux et souhaitez savoir ce que ce .well_knowndossier représente.

Quel client d'application aurait besoin d'accéder à un tel dossier et quelle application créerait des fichiers à l'intérieur de ce dossier ?

Voici quelques entrées du journal des erreurs PHP d'un de mes domaines. (J'ai supprimé la date, l'adresse IP et les domaines cibles).

0000/00/00 00:00:00 [error] 851#0: *88611 access forbidden by rule, client: xxx.xxx.xxx.xxx, server: example.com, request: "GET /.well-known/apple-app-site-association HTTP/1.1", host: "exampleA.com"
0000/00/00 00:00:00 [error] 850#0: *89749 access forbidden by rule, client: xxx.xxx.xxx.xxx, server: example.com, request: "GET /.well-known/assetlinks.json HTTP/1.1", host: "exampleA.com"
0000/00/00 00:00:00 [error] 850#0: *89767 access forbidden by rule, client: xxx.xxx.xxx.xxx, server: example.com, request: "GET /.well-known/assetlinks.json HTTP/1.1", host: "exampleB.com"
0000/00/00 00:00:00 [error] 853#0: *90120 access forbidden by rule, client: xxx.xxx.xxx.xxx, server: example.com, request: "GET /.well-known/apple-app-site-association HTTP/1.1", host: "exampleB.com"
0000/00/00 00:00:00 [error] 853#0: *90622 access forbidden by rule, client: xxx.xxx.xxx.xxx, server: example.com, request: "GET /.well-known/apple-app-site-association HTTP/1.1", host: "www.exampleB.com"
0000/00/00 00:00:00 [error] 853#0: *90926 access forbidden by rule, client: xxx.xxx.xxx.xxx, server: example.com, request: "GET /.well-known/assetlinks.json HTTP/1.1", host: "www.exampleA.com"
0000/00/00 00:00:00 [error] 854#0: *91780 access forbidden by rule, client: xxx.xxx.xxx.xxx, server: example.com, request: "GET /.well-known/apple-app-site-association HTTP/1.1", host: "exampleA.com"

J'ai d'abord pensé que je pouvais être celui qui avait généré cela, mais à l'époque, je n'avais ni accès ni travail à ces domaines. Et ces demandes d'accès proviennent de 3 de nos domaines. (avec différentes applications web)

INFO1 : Il semblerait que l'adresse IP provienne de Google-Bot (Crawler), mais quels sont les points si importants pour accéder à ces fichiers? (Nous n'avons pas ces fichiers dans les dossiers, vérifiés pour caché dans tous les répertoires racine du domaine.)

Ce /.well-known/sous - répertoire est défini parRFC 5785 RFC 8615

Il est de plus en plus courant que les protocoles Web exigent la découverte de règles ou d'autres informations sur un hôte ("métadonnées à l'échelle du site") avant de faire une demande. Par exemple, le Robots Exclusion Protocol (Protocole d’exclusion de robots) http://www.robotstxt.org/ indique un moyen permettant aux processus automatisés d’obtenir l’autorisation d’accéder aux ressources; De même, la plate-forme pour les préférences de confidentialité [W3C.REC-P3P-20020416] indique aux agents d'utilisateurs comment découvrir au préalable une politique de confidentialité.

Bien qu'il existe plusieurs moyens d'accéder aux métadonnées par ressource (par exemple, en-têtes HTTP, PROPFIND [RFC4918] de WebDAV), la surcharge perçue (en termes de latence perçue par le client et / ou de difficultés de déploiement) qui leur est associée les empêche souvent de les utiliser. ces scénarios.

Lorsque cela se produit, il est courant de désigner un "emplacement bien connu" pour ces données, afin de pouvoir les localiser facilement. Cependant, cette approche présente l’inconvénient de risquer des collisions, à la fois avec d’autres "lieux connus" de ce type et avec des ressources préexistantes.

Pour y remédier, ce mémo définit un préfixe de chemin dans HTTP (S) pour ces URIs « des endroits bien connus » , /.well-known/. Les spécifications futures qui doivent définir une ressource pour ces métadonnées à l'échelle du site peuvent enregistrer leur utilisation afin d'éviter les collisions et de minimiser l'impact sur l'espace URI des sites.

La raison pour laquelle vous voyez des erreurs d’interdiction d’accès peut être le résultat d’un blocage général des demandes de fichiers / dossiers cachés (chemins commençant par un point .).
Au cas où vous auriez un contenu utile dans /. well-known, cette Q & R pourrait vous intéresser.

Les emplacements dans ce répertoire sont ensuite utilisés à des fins spécifiques,

• /.well-known/apple-app-site-associationest pour IOS liens universels
• /.well-known/assetlinks.jsonest un lien d'actif numérique (Android)

Ces deux applications ayant un objectif similaire, elles permettent à l’exploitant du site de charger un visiteur d’ouvrir le site dans une application associée plutôt que dans le navigateur (mobile).

• /.well-known/acme-challenge/est l'emplacement de la norme proposée pour l' environnement de gestion automatique des certificats en tant qu'emplacement pour la validation d'identificateur HTTP utilisé par Let's Encrypt.

L'IANA gère une liste complète des sites connus attribués sur www.iana.org/assignments/well-known-uris/well-known-uris.xhtml et une liste similaire sur Wikipedia inclut également quelques adresses URI différentes qui ne sont pas attribuées officiellement. et enregistré par l'IANA.