“导航被阻止".从Chrome自定义标签重定向到Android应用时 [英] "Navigation is blocked" when redirecting from Chrome Custom Tab to Android app

问题描述

我正在现代化"我们的登录小部件，以将Chrome自定义标签用作

I'm 'modernizing' our login widget to use Chrome Custom Tabs as Google will start blocking OAuth requests using Webviews in a few months.

登录小部件可与我们的身份服务配合使用，该身份服务通过在Google/Facebook/的授权代码流中播放OAuth2客户端"，从而支持经典的用户名和密码"登录和社交登录. 因此，来自Google的授权代码将传递到此身份服务，该身份服务又为我们的登录小部件提供访问令牌.

The login widget works with our Identity Service, which supports classic 'username&password' login and Social Login, by playing the OAuth2 'Client' in an Authorization Code Flow with Google/Facebook/... So the authorization code from Google is delivered to this Identity Service, which in turn provides our login widget with an access token.

访问令牌通过客户端重定向传递回移动应用程序:

The access token is passed back to the mobile app through a client-side redirect:

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

经典登录的所有好处:用户填写用户名和密码并提交，返回访问令牌，并且重定向到自定义URI方案触发了我的RedirectReceiverActivity的意图过滤器.

All good for a classic login: user fills out username and password and submits, an access token is returned, and the redirect to the custom URI scheme triggers the intent-filter of my RedirectReceiverActivity.

但是，对于社交登录，重定向不会发生任何变化，除了Android Monitor中的以下行:

However, for a social login, nothing happens upon the redirect, except for this line in the Android Monitor:

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

请清楚一点:对于经典登录和社交登录，客户端重定向完全相同，但是在经典登录后允许它，而在社交登录后它被阻止！ 而且，如果我在微件中添加一个按钮，该按钮在社交登录后执行完全相同的重定向，则只要用户单击该按钮，就可以再次允许它.

Just to be clear: for both classic and social login, the client-side redirect is exactly the same, but after a classic login it is allowed while after a social login it is blocked!! And, if I add a button to the widget which does the exact same redirect after a social login, it is allowed again - as long as it is clicked by the user.

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

This leaves me puzzled: - Why is the redirect sometimes allowed and sometimes blocked? - Is there any way to get around this, other than asking the user to click a button after the social login sequence is finished?

我尝试了所有我能想到的东西:使用意图:"语法，模拟从代码中单击按钮，使用服务器端重定向，...但是没有任何效果. 另外，我还使用Google身份验证示例研究了 AppAuth库，据我所知正在做完全相同的事情.

I tried everything I could think of: using the "intent:" syntax, simulating a click on the button from code, using a server-side redirect,... but nothing works. Also, I studied the AppAuth libraries with the Google authentication example, and as far as I can tell I'm doing the exact same thing.

推荐答案

我是AppAuth的首席维护者.

I am the lead maintainer of AppAuth.

Chrome端用于触发重定向到应用程序的策略，无论是通过自定义方案还是通过https <应用程序链接是因为此操作必须由用户而不是Javascript触发.我相信这样做的目的是为了防止用户在站点打开应用程序时出现意外，而无需他们明确的同意"(单击链接的形式).

The policy on the Chrome side for triggering redirects to an app, whether through a custom scheme or an https App Link, is that this action must be triggered by the user, not Javascript. I believe the intention here is to prevent user surprise where a site opens an application without their explicit "consent" in the form of clicking on a link.

这对于身份提供者来说是有问题的，它们会根据授权请求立即重定向回重定向URI:在打开自定义"标签和重定向之间不会发生任何动作.

This is problematic for identity providers which immediately redirect back to the redirect URI on an authorization request: no action occurs between opening the custom tab and the redirect.

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

I maintain a demo that shows how to capture an OAuth redirect and forward it to the app after a user click here:

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

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

One other potential option is to capture the redirect parameters on your backend, and then respond to the browser with a 302 redirect to your custom scheme. As this maintains a single redirect "chain" from a user action, this should be permitted. Unfortunately this is much more complicated, as you would now likely have to use the OAuth2 state parameter as a key to retrieve the parameters from your server after the app redirect takes place. AppAuth can't directly help with that, as it expects the authorization response to be directly provided to it from the browser.

这篇关于“导航被阻止".从Chrome自定义标签重定向到Android应用时的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！