我实际上已经为此开发了一个解决方法。
我们创建了一个应用程序,该应用程序具有允许用户通过生成魔术访问链接来登录的功能。用户将下载并安装应用程序,输入他们的电子邮件地址,服务器将向他们发送一封电子邮件,其中包含以下形式的链接:https://www.example.com/app/accesslink/{{tokenHere}}
我们创建了一个 AASA 文件并将其上传到我们的域 (www.example.com),例如 :) https://developer.apple.com/library/content/documentation/General/Conceptual/AppSearch/UniversalLinks.html
大多数用户可以很好地生成访问链接,点击它,应用程序就会加载。我们在应用程序上有处理程序来获取令牌并对其进行身份验证等。
当一些电子邮件提供商重写电子邮件中的访问链接时,问题就出现了。这尤其发生在安装了 URLblocker 的企业用户身上。
为了解决这个问题,我们在服务器上创建了一个重写规则,将 www.example.com/app/accesslink/{{anythingHerer}} 重写为服务器上名为“404accesslink.html”的静态文件(文件名是 arbetary ,在这种情况下,服务器是 asp.net IIS)。然后我们编辑了 '404accesslink.html' 如下以包含以下元:
<script>
document.writeln('<meta name="apple-itunes-app" content="app-id={{APP_ID_HERE}}, app-argument=' + document.location.href + '">');
</script>
因为文件是通过重写提供的,所以 location.href 值与访问链接完全匹配。这欺骗了 iOS 打开应用程序并将路径传递给它。然后我们可以像往常一样在处理程序中提取它并验证用户。
我们写了一些简单的说明,以防打开应用程序不是自动的并且页面被显示(尽管在我们的测试中这没有发生)。
<!DOCTYPE html>
<html>
<head>
<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no">
<script>
document.writeln('<meta name="apple-itunes-app" content="app-id=XXXXXXXXXX, app-argument=' + document.location.href + '">');
</script>
<style>
body {
padding-top: 5%;
color: #FFF;
font-size: 1em;
font-family: Arial, Helvetica, sans-serif;
text-align: left;
background: #00338D;
margin: 50px;
}
h1 {
font-weight: normal;
font-size: 1.8em;
}
a {
color: #FFF;
font-weight: bold;
text-decoration: none;
}
</style>
<title>XXXXXXXXX</title>
<body>
<h1>Please select 'Open' in the app banner displayed at the top of this page to open the app with your access link.</h1>
<p>If you do not see the app banner above then please close your browser and sign into the app using your email address and the password you used to register for the event.</p>
<p>If you do not know your password then you can <a href="https://XXXXXXXXXXXXX/account/mobileforgot/">reset it by following this link</a>.</p>
<p>Thank you,</p>
<p>XXXXXXXXXXXXX team</p>
</body>
</html>
如果在服务器端设置和渲染元数据可能会更好,而不是使用 JS 客户端,但它仍然有效。
在此之前:
如果任何系统重写/包装了应用程序链接,则该应用程序不会与新 URL 关联,并且当用户点击该 URL 时,它会在 Safari 中打开。
完成后:
如果任何系统重写/包装了应用程序链接,则该应用程序不会与新 URL 关联,并且当用户点击该 URL 时,它会在应用程序中打开。