android - 从 Chrome 自定义选项卡重定向到 Android 应用时出现 "Navigation is blocked"

Question

我正在“现代化”我们的登录小部件以使用 Chrome 自定义选项卡作为 Google will start blocking OAuth requests using Webviews in a few months .

登录小部件与我们的身份服务配合使用，它支持经典的“用户名和密码”登录和社交登录，通过在授权代码流中与 Google/Facebook/...因此，来自 Google 的授权代码会传送到此身份服务，而身份服务又会为我们的登录小部件提供访问 token 。

访问 token 通过客户端重定向传回移动应用:

window.location.replace('com.acmeusercontent.tenants.abc:\/setTokenData?accessToken='+access_token+'#');

对于经典登录来说一切都很好:用户填写用户名和密码并提交，返回访问 token ，重定向到自定义 URI 方案会触发我的 RedirectReceiverActivity 的 intent-filter。

但是，对于社交登录，重定向时不会发生任何事情，除了 Android 监视器中的这一行:

I/chromium: [INFO:CONSOLE(0)] "Navigation is blocked: com.acmeusercontent.tenants.abc:/setTokenData..."

需要说明的是:对于经典登录和社交登录，客户端重定向完全相同，但在经典登录后允许，而在社交登录后则被阻止!!而且，如果我向小部件添加一个按钮，它在社交登录后执行完全相同的重定向，那么它会再次被允许 - 只要它被用户点击。

这让我感到困惑:- 为什么重定向有时被允许有时被阻止？- 除了要求用户在社交登录序列完成后单击按钮之外，是否有任何方法来解决这个问题？

我尝试了所有我能想到的方法:使用“intent:”语法，从代码中模拟点击按钮，使用服务器端重定向，......但没有任何效果。另外，我研究了AppAuth libraries使用 Google 身份验证示例，据我所知，我正在做完全相同的事情。

Answer 1

我是 AppAuth 的主要维护者。

Chrome 端用于触发重定向到应用程序的策略，无论是通过自定义方案还是 https App Link , 是这个 Action 必须由用户触发，而不是 Javascript。我相信这里的目的是防止用户在网站未经他们以点击链接的形式明确“同意”的情况下打开应用程序时感到惊讶。

这对于根据授权请求立即重定向回重定向 URI 的身份提供者来说是有问题的:在打开自定义选项卡和重定向之间没有发生任何操作。

我维护了一个演示，展示了如何在用户单击此处后捕获 OAuth 重定向并将其转发到应用程序:

https://github.com/iainmcgin/AppAuth-Demo

另一个可能的选择是在您的后端捕获重定向参数，然后使用 302 重定向响应浏览器到您的自定义方案。由于这维护了来自用户操作的单个重定向“链”，因此应该允许这样做。不幸的是，这要复杂得多，因为您现在可能必须使用 OAuth2 状态参数作为键，以便在应用程序重定向发生后从您的服务器检索参数。 AppAuth 不能直接提供帮助，因为它希望授权响应直接从浏览器提供给它。