Android上的Chrome 61+中的导航被阻止错误 [英] Navigation is blocked error in Chrome 61+ on Android
问题描述
我正在构建一个登录页面，该页面在提交并验证用户凭据后会打开一个本机移动应用程序.直到上周，我通过使用自定义方案URI来实现跨移动OS的工作，例如:
I'm building a login page that, upon submitting and validation of the user credentials, opens up a native mobile application. Up till last week, I had this working cross mobile OS by using a custom scheme URI, something like:
function onLoginCallback() {
const redirectUri = 'customscheme:/action?param1=val1¶m2=val2';
window.location.replace(redirectUri);
}
登录页面显示在IABT中，是应用程序内浏览器"选项卡的缩写.
The login page is displayed in an IABT, short for In App Browser Tab.
但是，自Chrome 61版本发布以来，这种方法在Android上已被打破. Chrome浏览器会阻止重定向，因为没有明显的用户操作与重定向相关(有关更多信息，请参见此处)有关此问题的信息).
However, since the release of version 61 of Chrome, this is approach is broken on Android. Chrome blocks the redirect because there's no apparent user action related to the redirect (see here for more information on the matter).
因此，当执行上面的代码时，我将在控制台中收到警告:
As a consequence, when executing the code above, I'll end up with a warning in the console:
导航被阻止:customcheme:/action?param1 = val1& param2 = val2
Navigation is blocked: customscheme:/action?param1=val1¶m2=val2
我也尝试过将自定义方案网址更新为意图网址，但无济于事.谷歌搜索这个问题并不能提供一个明确的解决方案，所以我希望任何人都可以帮助我.
尝试在以下情况下(尽可能接近实际情况)重现该问题:
I've also tried updating the custom scheme url to an intent url but to no avail. Googling about this issue doesn't readily provide a clear solution, so I'm hoping anyone on can help me out.
Tried to reproduce the issue with the following scenario (as close as possible to the real life scenario):
- IABT使用一个按钮显示一个页面
- 单击按钮会向模拟端点触发jsonp调用
- 执行JSONP回调并触发自定义事件
- 触发自定义事件的事件处理程序，并将浏览器重定向到另一个模拟端点
- 该模拟端点以302响应自定义的深层链接方案.
A，这似乎可行.我本来希望包含jsonp调用会导致Chrome阻止最终重定向，因为它无法将其识别为用户发起的操作.
Alas, this seems to be working. I would have expected that the inclusion of the jsonp call would cause Chrome to block the final redirect as it would not be able to identify it as a user initiated action.
进行管理以获取可重现的方案.我们已经建立了一个虚拟端点，该端点可以根据请求简单地在Location标头中返回带有自定义方案的
302.除第一次尝试外，此方法在所有尝试中均被阻止.这个事实仍然令人困惑.我们正在使用适用于Android的AppAuth 应用程序来测试设置.
Edit 2: Managed to get a reproducible scenario. We've set up a dummy endpoint, that upon request simply returns a
302 with the custom scheme in the Location header. This is blocked on all tries, except for the first one. That fact still boggles the mind. We're using the AppAuth for Android application to test the setup.
我正在向端点打开一个自定义选项卡，如下所示.该代码摘自此答案.
I'm opening a custom tab to the endpoint as shown below. The code is taken from this answer.
void launchTab(Context context, Uri uri){
final CustomTabsServiceConnection connection = new CustomTabsServiceConnection() {
@Override
public void onCustomTabsServiceConnected(ComponentName componentName, CustomTabsClient client) {
final CustomTabsIntent.Builder builder = new CustomTabsIntent.Builder();
final CustomTabsIntent intent = builder.build();
client.warmup(0L); // This prevents backgrounding after redirection
intent.launchUrl(context, uri);
}
@Override
public void onServiceDisconnected(ComponentName name) {
}
};
CustomTabsClient.bindCustomTabsService(context, "com.android.chrome", connection);
}
推荐答案
我们最终使用服务器以302响应自定义URI方案.由于在此设置中，在提交表单的用户与接收重定向的浏览器之间没有异步执行，因此Chrome可以正确地将操作链标识为受信任，因此不会阻止导航.
The server responds with a 302 to the custom URI scheme. Because in this setup there's no asynchronous execution between the user submitting the form and the browser receiving a redirect, Chrome correctly identifies the chain of actions as trusted and thus will not block the navigation.
我意识到这可能不是每个人的首选解决方案.支持异步执行流程的一种可能替代方法是使用通用链接常规的http(s)方案，Chrome认为重定向到(在发布我的问题时)重定向有害.
I realise this might not be the preferred solution for everyone. A possible alternative to support asynchronous execution flows is the use of universal links as these use regular http(s) schemes, to which redirects were (at the time of posting my question) not considered harmful by Chrome.
这篇关于Android上的Chrome 61+中的导航被阻止错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
