Подтвердить что ты не робот

Запросы на/.well-known/apple-app-site-association

Я только что проверил журналы своего сервера и обнаружил, что следующие странные запросы поступают довольно много. У меня реализована универсальная привязка IOS 9, но эти запросы работают против /apple -app-site-association, насколько мне известно.

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

Кто-нибудь еще видел эти шаблоны? Известно ли это спам или что-то еще?

4b9b3361

Ответ 1

Я полагаю, что iOS 9.3 представила немного другую логику поиска вокруг файла ассоциации Apple-app-site и функции передачи обслуживания приложения.

"Handoff сначала ищет файл в хорошо известном подкаталоге (например, https://example.com/.well-known/apple-app-site-association), возвращаясь в домен верхнего уровня, если вы не используйте хорошо известный подкаталог.

см. https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/Handoff/AdoptingHandoff/AdoptingHandoff.html#//apple_ref/doc/uid/TP40014338-CH2-SW10

Ответ 2

Я также получил следующее в своем журнале:

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

Где XXX в журнале находится число от 0 до 255.

Затем я проверил Whois IP 66.249.69.0, 1, 2....... 255

И что я нашел, все IP в диапазоне от 66.249.64.0 - 66.249.95.255, присвоенный Google Inc. Подождите, вы издеваетесь надо мной, почему google запрашивает apple-app-site-association на моем сервере?

Поскольку Google расширяет его сопоставление, чтобы включить информацию об ассоциациях между веб-сайтами и конкретными приложениями iOS для Индексирование приложений Google для универсальных ссылок из Google Search в Safari..

Журнал Whois для 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

Ответ 3

Мы также видим это поведение. Подавляющее большинство файлов журнала доступа к серверу теперь запрашивают этот конкретный файл.

Если вы запускаете настройку с помощью nginx, обслуживающего статические файлы перед сервером/картой приложения, убедитесь, что файлы /.well-known/apple-app-site-association AND /apple-app-site-association либо существуют, либо возвращают ответ.

Если они этого не сделают, пропущенные запросы будут переданы вместе с вашей инфраструктурой, что во многих случаях приведет к обработке ваших маршрутов, прежде чем определять, что совпадения нет. Пока мы не сделали это изменение вчера, добавленное напряжение для наших серверов было довольно значительным.

Ответ 4

Я вижу много этих запросов (как с подпапкой .well-known, так и без нее). Они происходят от google-bot, но я полагаю, что другие пауки могут начать искать их тоже в какой-то момент. Поскольку мой сайт не имеет каких-либо перекрывающихся функциональных возможностей с любым приложением iOS (или Android), это пустая трата пропускной способности. Мне нравится @aramisbear ответ для защиты моего сервера приложений (fooobar.com/info/137341/...). Но я попытаюсь добавить их к моему robots.txt. Поскольку google-bot соответствует robots.txt (и другие боты, заинтересованные в создании индексов приложений, почти наверняка тоже), я бы предположил, что это сделает невозможным тратить даже мою пропускную способность прокси-сервера nginx.