web-dev-qa-db-ja.com

/.well-known/Apple-app-site-associationへのリクエスト

サーバーログを確認したところ、次のような奇妙なリクエストが非常に多く発生していることがわかりました。 iOS 9 Universal Linkingを実装していますが、それらのリクエストは、私の知る限り/ Apple-app-site-associationに対して実行されています。

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

他の人はこれらのパターンを見ましたか？これは既知のスパム行為ですか？

iosios-universal-links
51
Tim Specht

iOS 9.3では、Apple-app-site-associationファイルとアプリのハンドオフ機能に関して、少し異なるルックアップロジックが導入されたと考えています。

「Handoffは、最初に.well-knownサブディレクトリ（たとえば、 https://example.com/.well-known/Apple-app-site-association ）でファイルを検索し、 .well-knownサブディレクトリを使用しない場合は、トップレベルドメイン。」

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

31
busticated

また、ログに次のメッセージが表示されました。

[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. 、 1 、 2 ....... 255 をチェックしました

そして、私が見つけたのは、 66.249.64. - 66.249.95.255 の範囲のすべてのIPがGoogle Incに割り当てられていることです。冗談でしょうか、GoogleがサーバーでApple-app-site-associationをリクエストするのはなぜですか？

Googleがマッピングを拡張して、Webサイトと特定のiOSアプリとの関連付けに関する情報を含めるようにしました SafariでのGoogle検索からのユニバーサルリンクのGoogleアプリのインデックス作成 。

IP 66.249.64.0のWhoisログ

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

この動作も見られます。現在、サーバーのアクセスログファイルの大部分は、この特定のファイルに対する要求です。

アプリケーションサーバー/フレームワークの前で静的ファイルを提供するnginxを使用してセットアップを実行している場合は、/.well-known/Apple-app-site-association AND /Apple-app-site-associationファイルが存在するか、応答を返すことを確認してください。

一致しない場合、欠落しているリクエストはすべてフレームワークに渡されるため、多くの場合、一致しないと判断する前にルートを処理する必要があります。昨日その変更を行うまで、サーバーへの追加のストレスはかなり大きなものでした。

5
brightball

これらのリクエストの多くが見られます（.well-knownサブディレクトリの有無にかかわらず）。それらはgoogle-botからのものですが、他のスパイダーもある時点でそれらを探し始めるかもしれません。私のサイトには、iOS（またはAndroid）アプリと重複する機能がないため、帯域幅の無駄です。アプリケーションサーバーを保護する@aramisbearの回答が気に入っています（ https://stackoverflow.com/a/36185061/46759 ）。しかし、代わりにrobots.txtに追加してみます。 google-botはrobots.txtを尊重するため（アプリインデックスの作成に関心のある他のボットもほぼ間違いなくそうです）、これを行うことでnginxプロキシの帯域幅も浪費されなくなると思います。

3
sootsnoot

IOS 9.3以降、Appleは最初に/.well-known/Apple-app-site-associationをダウンロードしようとし、失敗した場合は/Apple-app-site-associationにフォールバックします。

Appleの Technical Q＆A QA1919 を参照してください。

/.well-known/Apple-app-site-associationファイルの着信リクエスト

Q：Webサーバーが https://example.com/.well-known/Apple-app-site-association のリクエストを受信するのはなぜですか？

A：最近リリースされたiOS 9.3アップデートは、 RFC 5785 を実装しています。このため、iOS 9.3を実行するデバイスは、最初に niversal Links および Shared Web Credentials の実装に必要な/.well-known/Apple-app-site-associationファイルのApple-app-site-associationを要求します。この場所でファイルが見つからない場合、デバイスは以前のリリースのiOS 9と同様に、Webサーバーのルートにあるファイルを要求します。

1
Marián Černý