web-dev-qa-db-fra.com

Demandes à /.well-known/Apple-app-site-association

Je viens de vérifier les journaux de mon serveur et j'ai trouvé les demandes étranges suivantes qui arrivaient beaucoup. J'ai iOS 9 Universal Linking mis en œuvre, mais ces demandes sont exécutées contre/association Apple-app-site-site autant que je sache.

Jan 15 09:36:23 method=GET path="/.well-known/Apple-app-site-association"

Est-ce que quelqu'un d'autre a vu ces modèles? Est-ce un spam connu ou quelque chose comme ça?

iosios-universal-links
51
Tim Specht

je crois que iOS 9.3 a introduit une logique de recherche légèrement différente autour du fichier d'association Apple-app-site-site et de la fonctionnalité de transfert d'application.

"Handoff commence par rechercher le fichier dans le sous-répertoire .well (par exemple, https://example.com/.well-known/Apple-app-site-association ), en revenant à le domaine de premier niveau si vous n'utilisez pas le sous-répertoire .well. "

voir: https://developer.Apple.com/library/ios/documentation/UserExperience/Conceptual/Handoff/AdoptingHandoff/AdoptingHandoff.html#//Apple_ref/doc/uid/TP40014338-CH2-SW1

31
busticated

J'ai aussi reçu ce qui suit dans mon journal:

[Mon Feb 29 12:34:53 2016] [error] [source 66.249.75.XXX] File does not exist: /public_path/Apple-app-site-association

Où XXX dans le journal est un nombre compris entre 0 et 255.

Ensuite, j'ai vérifié Whois IP 66.249.69. , 1 , 2 ....... 255

Et ce que j'ai trouvé, Toutes les adresses IP comprises entre 66.249.64. - 66.249.95.255 attribuées à Google Inc. Attends, tu te moques de moi, pourquoi google demande-t-il Apple-app-site-association sur mon serveur?

Parce que Google étend sa cartographie pour inclure des informations sur les associations entre des sites Web et des applications iOS spécifiques pour Index des applications Google pour les liens universels depuis Google Search dans Safari. .

Journal Whois pour IP 66.249.64.0

NetRange:       66.249.64.0 - 66.249.95.255
CIDR:           66.249.64.0/19
NetName:        GOOGLE
NetHandle:      NET-66-249-64-0-1
Parent:         NET66 (NET-66-0-0-0-0)
NetType:        Direct Allocation
OriginAS:       
Organization:   Google Inc. (GOGL)
RegDate:        2004-03-05
Updated:        2012-02-24
Ref:            https://whois.arin.net/rest/net/NET-66-249-64-0-1



OrgName:        Google Inc.
OrgId:          GOGL
Address:        1600 Amphitheatre Parkway
City:           Mountain View
StateProv:      CA
PostalCode:     94043
Country:        US
RegDate:        2000-03-30
Updated:        2015-11-06
Ref:            https://whois.arin.net/rest/org/GOGL


OrgAbuseHandle: ABUSE5250-ARIN
OrgAbuseName:   Abuse
OrgAbusePhone:  +1-650-253-0000 
OrgAbuseEmail:  [email protected]
OrgAbuseRef:    https://whois.arin.net/rest/poc/ABUSE5250-ARIN

OrgTechHandle: ZG39-ARIN
OrgTechName:   Google Inc
OrgTechPhone:  +1-650-253-0000 
OrgTechEmail:  [email protected]
OrgTechRef:    https://whois.arin.net/rest/poc/ZG39-ARIN
14
Vineet Choudhary

Nous constatons également ce comportement. La grande majorité des fichiers journaux d'accès de notre serveur sont maintenant des demandes pour ce fichier particulier.

Si vous exécutez une configuration avec nginx servant des fichiers statiques devant un serveur/framework d’applications, assurez-vous de vérifier que le /.well-known/Apple-app-site-association ET /Apple-app-site-association Les fichiers existent ou renvoient une réponse.

S'ils ne le font pas, les demandes manquantes seront toutes transmises à votre infrastructure, ce qui obligera souvent à traiter vos itinéraires avant de déterminer qu'il n'y a pas de correspondance. Jusqu'à ce que nous apportions ce changement hier, le stress supplémentaire imposé à nos serveurs était assez important.

5
brightball

Je vois beaucoup de ces demandes (avec et sans le .well-known sous-répertoire). Ils viennent de google-bot, mais je suppose que d’autres araignées pourraient aussi commencer à les chercher à un moment donné. Étant donné que mon site ne présente aucune fonctionnalité qui se chevauche avec aucune application iOS (ou Android), il s’agit d’un gaspillage de bande passante. J'aime la réponse de @ aramisbear pour protéger mon serveur d'applications ( https://stackoverflow.com/a/36185061/46759 ). Mais je vais essayer de les ajouter à mon robots.txt au lieu. Puisque google-bot respecte robots.txt (et d’autres bots intéressés par la création d’index d’applications le feraient certainement aussi) Je suppose que cela évitera de gaspiller même la bande passante de mon nginx proxy, également.

3
sootsnoot

Depuis iOS 9.3 Apple va d'abord essayer de télécharger /.well-known/Apple-app-site-association Et s'il échoue, il se replie sur /Apple-app-site-association.

Voir le Questions techniques QA1919 :

Demandes entrantes pour le fichier /.well-known/Apple-app-site-association

Q: Pourquoi mon serveur Web reçoit-il des demandes pour https://example.com/.well-known/Apple-app-site-association ?

R: La mise à jour iOS 9.3 récemment publiée implémente RFC 5785 . C'est pourquoi les appareils exécutant iOS 9.3 demandent d'abord /.well-known/Apple-app-site-association Au fichier Apple-app-site-association Requis pour la mise en œuvre liens universels et informations d'identification Web partagées =. Si le fichier ne se trouve pas à cet emplacement, l'appareil le demandera à la racine du serveur Web, comme dans les versions précédentes d'iOS 9.

1
Marián Černý