web-dev-qa-db-fra.com

Qu'est-ce que le dossier ".connu"?

Si vous avez trouvé un nouveau message d'erreur dans nos fichiers journaux et que vous souhaitez savoir, pour quoi cela .well_known- dossier signifie.

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

Voici quelques entrées du PHP Journal des erreurs de l'un de mes domaines. (J'ai supprimé les domaines date, ip et target)).

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'accédais/ne travaillais pas sur ces domaines. Et ces demandes d'accès proviennent de 3 de nos domaines. (avec différentes applications Web)


INFO1: Il semble que l'IP provient du Google-Bot (Crawler) Mais qu'est-ce qui est si important pour accéder à ces fichiers? (nous n'avons pas ces fichiers dans les dossiers, vérifiés pour cachés dans tous les répertoires racine du domaine.)

56
Sascha

Cette /.well-known/ le sous-répertoire est défini par RFC 5785RFC 8615

Il est de plus en plus courant que les protocoles Web exigent la découverte d'une politique 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 http://www.robotstxt.org/ spécifie un moyen pour les processus automatisés d'obtenir la permission 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 utilisateurs comment découvrir au préalable la politique de confidentialité.

Bien qu'il existe plusieurs façons d'accéder aux métadonnées par ressource (par exemple, les 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 empêche souvent leur utilisation dans ces scénarios.

Lorsque cela se produit, il est courant de désigner un "emplacement connu" pour ces données, afin qu'elles puissent être facilement localisées. Cependant, cette approche présente l'inconvénient de risquer des collisions, à la fois avec d'autres tels "emplacements bien connus" et avec des ressources préexistantes.

Pour résoudre ce problème, ce mémo définit un préfixe de chemin dans les URI HTTP (S) pour ces "emplacements connus", /.well-known/. Les spécifications futures qui doivent définir une ressource pour de telles métadonnées à l'échelle du site peuvent enregistrer leur utilisation pour éviter les collisions et minimiser l'impact sur l'espace URI des sites.

La raison pour laquelle vous voyez des erreurs d'accès interdit peut être le résultat d'un bloc de couverture sur les demandes de fichiers/dossiers cachés (chemins commençant par un point .).
Si vous avez un contenu utile dans /.well-known, ce Q&R peut être intéressant.

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

Tous deux soutiennent un objectif similaire, ils permettent à l'opérateur du site de demander à un visiteur d'ouvrir le site dans une application associée, plutôt que dans le navigateur (mobile).

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

77
HBruijn