【问题标题】:iOS Associated Domains - subdomains seems to be ignorediOS 相关域 - 子域似乎被忽略了
【发布时间】:2017-12-20 15:41:13
【问题描述】:

我有两种构建配置:AppApp Stage

每个配置都有不同的Associated Domains 配置:app.mydomain.comapp-stage.mydomain.com

当然,每个网站都会公开不同的apple-app-site-association 文件:app.mydomain.com/apple-app-site-associationapp-stage.mydomain.com/apple-app -site-association(HTTP 200,不带 .json 扩展名等)。

问题是只有第一个注册的域(不幸的是它是 Stage)才能正常工作。当我安装了这两个应用程序后,每个深层链接(app.mydomain.com/homeapp-stage.mydomain.com/home)都会打开 App Stage。当我只安装了 App Sage 时,两个链接也会打开它。当我只安装了应用程序时,没有链接工作。 看起来Associated Domains 的子域被忽略了,并且只考虑了 mydomain.com

我假设构建配置定义正确,因为我也在区分其他设置,如 Facebook、Google 和其他。

你有没有遇到过类似的问题? Associated Domains是否允许使用同一域的不同子域?

更新:

按照@clayjones94 的说明,我检查了每个应用程序是否使用 Charles Proxy 下载了正确的 JSON 文件。 我发现 App Stage 正在获取正确的文件,而 App 没有获取任何文件。

我还在 Charles 的 app-stage.mydomain.com/apple-app-site-association HTTP 请求中编辑了 URL,以确保 app.mydomain.com/apple- app-site-association 返回正确的 JSON。当我从 URL 中删除 -stage 并重复调用时,它获取了一个不同的 JSON 文件,因此我确认后端对于这两种配置都正常工作。

首先我认为我的构建配置不正确。所以我决定将 App 的 applinks:app.mydomain.com 关联域替换为 Stage 的 applinks:app-stage.mydomain.com 以查看 App 配置是否能够获取 App Stage 文件。它起作用了,应用程序已经下载了 App Stage 的 JSON 文件。同样,看起来Associated Domains 的子域被忽略了,并且只考虑了第一个注册的子域。

【问题讨论】:

  • 您能否在您的服务器上查看您的访问日志以了解所请求的内容? mydomain.com/apple-app-site-association 提供什么服务吗?
  • 是的,它可以成功获取(HTTP 200),它看起来与阶段子域apple-app-site-association 文件几乎相同 - 只是捆绑标识符不同(两个应用程序在同一个团队中) .

标签: ios iphone deep-linking associated-domains


【解决方案1】:

就通用链接(应用程序域)而言,没有域和子域的概念。我猜应该是 apple-site-association-file 配置存在问题。

请检查关于 appID 字段的 apple-site-association-configurations。我怀疑您可能在两个文件中放置了相同的 appID。

这两种配置应该有不同的 appID。

【讨论】:

  • 感谢您的回复。 apple-app-site-association 文件不同,Stage App appID 条目:"appID": "3U******2D.de.k****a.app-stage",App appID 条目:"appID": "3U******2D.de.k****a.app"。我希望这不是一个 iOS 错误,就像 iOS11 上的无提示通知一样...
  • 您还有其他相关的域吗?
  • 不,只有这个。
【解决方案2】:

拉取 Apple App Site Association 文件时,您的操作系统应分别拉取两者。我建议删除这两个应用程序并重新启动手机,以确保没有旧的 AASA 文件被缓存。

当您将应用重新安装到手机上时,您可以使用 Charles Proxy 查看每次安装是否提取了正确的 AASA 文件。由于您在关联域中都有这两个 URL,因此每次安装都将拉下两个 AASA 文件。如果您的生产应用程序没有拉下两者,则可能是Apple issue,您只需删除该应用程序并重试。

如果您验证每个应用程序的两个 AASA 文件都被拉下,那么您应该验证应用程序 ID 是否正确(您似乎拥有)。当两个应用程序都具有关联的域和具有正确 appID 的 AASA 文件时,您的操作系统应根据链接打开正确的应用程序。如果这仍然不起作用,则可能意味着您的 AASA 文件已由与您的暂存应用相关联的权利签名,而不是您的生产应用。

我建议使用Branch 进行通用链接。 Branch 有测试链接,您可以使用它们来测试您的 prod 应用程序的链接,并且您应该能够在 Branch 上为您的 staging 应用程序创建一个单独的应用程序,这样您就可以为这两个应用程序提供不同的链接。好消息是我们将为您完成所有的 AASA 处理和签名。深度链接服务是免费的,我们执行延迟深度链接:)。

【讨论】:

  • 感谢您的回复!当我使用 Charles 验证每个应用程序是否正在下载正确的文件时,我发现当 App Stage 正在下载正确的文件时,App 并没有下载任何 AASA 文件!现在我正在调查原因。
  • 请检查更新的问题。当我为应用程序使用 App Stage 关联域时(刚刚将 -stage 添加到 Xcode 中的域中),应用程序已下载 App Stage JSON 文件(以前它没有获取任何内容)。
  • 嗯,这不应该是这样。分支应用程序实际上会从 2 个不同的子域中获取 AASA 文件。对于每个应用程序,我们都有一个类似于您的-stage-alternate。当用户在原始子域上并想要深度链接到应用程序时,使用备用域(如果用户在该域上,Apple 有一个限制,即不允许通用链接转到本机应用程序)。在 q1hv.app.link/apple-app-site-association 查看我的测试应用程序 AASA 和 q1hv-alternate.app.link/apple-app-site-association 的备用 AASA。您的 App 的 AASA 文件似乎未正确托管。
  • 谢谢你的例子,它让我相信这不应该是问题,我应该继续努力。如果我发现任何其他问题,我会更新问题。
猜你喜欢
  • 2021-10-28
  • 2016-09-30
  • 2012-03-11
  • 1970-01-01
  • 1970-01-01
  • 2017-12-05
  • 2012-03-08
  • 2015-12-11
  • 2014-04-15
相关资源
最近更新 更多