Запросы на/.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"
Кто-нибудь еще видел эти шаблоны? Известно ли это спам или что-то еще?
Ответы
Ответ 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
.