请求/.well-known/apple-app-site-association

时间：2016-01-15 13:26:58

标签： ios ios-universal-links

我刚检查了我的服务器日志，发现以下奇怪的请求进入了很多。我已经实现了iOS 9 Universal Linking，但据我所知，这些请求是针对/ apple-app-site-association运行的。

public class InactiveReceiver extends BroadcastReceiver {

  public InactiveReceiver() {
  }

  @Override public void onReceive(Context context, Intent intent) {
    SharedPreferences preferences = context.getSharedPreferences("inactive", Context.MODE_PRIVATE);
    long time = preferences.getLong("time", 0);
    int trial = preferences.getInt("trial", 0);
    Log.e("inactive_check", "receive " + new SimpleDateFormat().format(
        new Date(Calendar.getInstance().getTimeInMillis())));

    switch (trial) {
      case 0: {
        makeNotification(context, trial);
        AlarmManager am = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
        Intent i = new Intent(context, InactiveReceiver.class);
        PendingIntent pIntent =
            PendingIntent.getBroadcast(context, 9977, i, PendingIntent.FLAG_UPDATE_CURRENT);
        if (Build.VERSION.SDK_INT < 19) {
          am.set(AlarmManager.RTC_WAKEUP, time, pIntent);
        } else {
          am.setExact(AlarmManager.RTC_WAKEUP, time, pIntent);
        }
        preferences.edit().putInt("trial", trial + 1).commit();
      }
      break;
      case 1: {
        makeNotification(context, trial);

        AlarmManager am = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
        Intent i = new Intent(context, InactiveReceiver.class);
        PendingIntent pIntent =
            PendingIntent.getBroadcast(context, 9977, i, PendingIntent.FLAG_UPDATE_CURRENT);
        if (Build.VERSION.SDK_INT < 19) {
          am.set(AlarmManager.RTC_WAKEUP, time, pIntent);
        } else {
          am.setExact(AlarmManager.RTC_WAKEUP, time, pIntent);
        }
        preferences.edit().putInt("trial", trial + 1).commit();
      }
      break;
      case 2: {
        makeNotification(context, trial);
        preferences.edit().putInt("trial", trial + 1).commit();
      }
      break;
    }
  }

  private static void makeNotification(Context context, int trial) {
    Intent intent = new Intent(context, LoginActivity.class);
    // use System.currentTimeMillis() to have a unique ID for the pending intent
    PendingIntent pIntent =
        PendingIntent.getActivity(context, (int) System.currentTimeMillis(), intent,
            PendingIntent.FLAG_UPDATE_CURRENT);
    String subject;
    switch (trial) {
      case 0:
        subject = "Твои новые клиенты - это друзья друзей ";
        break;
      case 1:
        subject = "Номерок. Много клиентов не бывает";
        break;
      case 2:
        subject = "500 новых клиентов за 2 месяца - легко. Начни сейчас!";
        break;
      default:
        subject = "Твои новые клиенты -это друзья друзей ";
    }
    // build notification
    // the addAction re-use the same intent to keep the example short
    Notification n = new NotificationCompat.Builder(context).setContentTitle("Вы давно не заходили")
        .setContentText(subject)
        .setSmallIcon(R.drawable.ic_launcher)
        .setContentIntent(pIntent)
        .setAutoCancel(true)
        .build();

    NotificationManager notificationManager =
        (NotificationManager) context.getSystemService(Context.NOTIFICATION_SERVICE);

    notificationManager.notify(9978, n);
  }

  public static void cancellInActiveCheck(Context context) {
    SharedPreferences preferences = context.getSharedPreferences("inactive", Context.MODE_PRIVATE);
    preferences.edit().clear().commit();
    AlarmManager am = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
    Intent i = new Intent(context, InactiveReceiver.class);
    PendingIntent intent =
        PendingIntent.getBroadcast(context, 9977, i, PendingIntent.FLAG_UPDATE_CURRENT);
    am.cancel(intent);
  }

  public static void setInActiveCheck(Context context) {
    SharedPreferences preferences = context.getSharedPreferences("inactive", Context.MODE_PRIVATE);
    Calendar c = Calendar.getInstance();
    long time = c.getTimeInMillis();
    SharedPreferences.Editor editor = preferences.edit();
    editor.putLong("time", time);
    editor.putInt("trial", 0);
    editor.commit();

    AlarmManager am = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
    Intent i = new Intent(context, InactiveReceiver.class);
    PendingIntent intent =
        PendingIntent.getBroadcast(context, 9977, i, PendingIntent.FLAG_UPDATE_CURRENT);
    time = getTime(1);
    Log.e("inactive_check", "set " + new SimpleDateFormat().format(new Date(time)));

    if (Build.VERSION.SDK_INT < 19) {
      am.set(AlarmManager.RTC_WAKEUP, time, intent);
    } else {
      am.setExact(AlarmManager.RTC_WAKEUP, time, intent);
    }
  }

  private static long getTime(int days) {
    return TimeUnit.MILLISECONDS.convert(days, TimeUnit.MINUTES) + Calendar.getInstance()
        .getTimeInMillis();
  }
}

还有其他人看过这些模式吗？这是一些已知的垃圾邮件吗？

5 个答案:

答案 0 :(得分：29)

我相信iOS 9.3围绕apple-app-site-association文件和app handoff功能引入了略微不同的查找逻辑。

＆＃34; Handoff首先搜索.well-known子目录中的文件（例如https://example.com/.well-known/apple-app-site-association），如果不使用.well-已知，则回退到顶级域名。子目录＆＃34;

请参阅：https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/Handoff/AdoptingHandoff/AdoptingHandoff.html#//apple_ref/doc/uid/TP40014338-CH2-SW10

答案 1 :(得分：14)

我还在日志中收到以下内容：

[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扩展了它的映射，以包含有关Google App Indexing for universal links from Google Search in Safari.网站和特定iOS应用之间关联的信息。

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@google.com
OrgAbuseRef:    https://whois.arin.net/rest/poc/ABUSE5250-ARIN

OrgTechHandle: ZG39-ARIN
OrgTechName:   Google Inc
OrgTechPhone:  +1-650-253-0000 
OrgTechEmail:  email@google.com
OrgTechRef:    https://whois.arin.net/rest/poc/ZG39-ARIN

答案 2 :(得分：5)

我们也看到了这种行为。我们绝大多数服务器的访问日志文件现在都是对此特定文件的请求。

如果您正在运行使用nginx在应用程序服务器/框架前提供静态文件的安装程序，请确保验证/.well-known/apple-app-site-association AND /apple-app-site-association文件是否存在或返回响应。

如果他们没有，那么缺失的请求将全部传递给您的框架，这在许多情况下导致必须在确定没有匹配之前处理您的路由。在我们昨天做出改变之前，对我们服务器的额外压力是相当大的。

答案 3 :(得分：3)

我看到很多这些请求（包含和不包含.well-known子目录）。它们来自google-bot，但我想其他蜘蛛也可能会在某些时候开始寻找它们。由于我的网站与任何iOS（或Android）应用没有任何重叠功能，因此浪费了带宽。我喜欢@ aramisbear的答案来保护我的应用服务器（https://stackoverflow.com/a/36185061/467590）。但我会尝试将它们添加到我的robots.txt中。由于google-bot尊重robots.txt（以及其他对创建应用程序索引感兴趣的机器人几乎肯定也会这样做），我认为这样做可以防止浪费我的nginx代理带宽。

答案 4 :(得分：1)

自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文件的传入请求

     

问：为什么我的Web服务器收到对https://example.com/.well-known/apple-app-site-association的请求？

     

A：最近发布的iOS 9.3更新实现了RFC 5785。因此，运行iOS 9.3的设备将首先向/.well-known/apple-app-site-association请求实现Universal Links和Shared Web Credentials所需的apple-app-site-association文件。如果在此位置找不到该文件，则设备将在Web服务器的根目录中请求该文件，就像iOS 9的先前版本一样。

相关问题
最新问题