我正在"现代化"我们的登录小部件以使用Chrome自定义标签,因为Google将在几个月内开始使用网页浏览来阻止OAuth请求.
登录小部件与我们的身份服务一起使用,该服务支持经典的"用户名和密码"登录和社交登录,通过Google/Facebook /授权代码流中的OAuth2"客户端"播放...因此Google的授权代码将传送给此身份服务,它又为我们的登录窗口小部件提供访问令牌.
访问令牌通过客户端重定向传递回移动应用程序:
window.location.replace('com.acmeusercontent.tenants.abc:\/setTokenData?accessToken='+access_token+'#');
一切都适合经典登录:用户填写用户名和密码并提交,返回访问令牌,重定向到自定义URI方案会触发我的RedirectReceiverActivity的intent-filter.
但是,对于社交登录,重定向没有任何反应,除了Android监视器中的这一行:
I/chromium: [INFO:CONSOLE(0)] "Navigation is blocked: com.acmeusercontent.tenants.abc:/setTokenData..."
需要明确的是:对于经典登录和社交登录,客户端重定向完全相同,但在经典登录后,允许在社交登录后被阻止!并且,如果我向窗口小部件添加一个按钮,该按钮在社交登录后执行完全相同的重定向,则只要用户单击它就可以再次允许.
这让我感到困惑: - 为什么重定向有时会被允许,有时会被阻止？- 除了要求用户在社交登录序列完成后单击按钮之外,还有什么方法可以解决这个问题吗？
我尝试了我能想到的一切:使用"intent:"语法,使用服务器端重定向模拟从代码中单击按钮,......但没有任何作用.此外,我使用Google身份验证示例研究了AppAuth库,据我所知,我做的完全相同.