延迟后刷新时插件身份验证不会自动完成

我为 Banno Mobile & Online 构建了一个插件，并且 OAuth 身份验证几乎适用于所有情况。然而，在移动应用程序的正常使用过程中，用户有时会遇到 Banno SSO 登录屏幕，提示他们输入用户名和密码，尽管他们已经登录到平台。当应用程序打开大约 10 分钟以上时，就会发生这种情况。我还注意到，这种情况仅发生在某些会刷新显示插件的仪表板的操作中。我根据行为将操作分为三类：

1. 不会导致插件重新加载：

   • 向下拖动屏幕/“刷新”仪表板手势
   • 暂停应用程序并重新打开
   • 锁定/解锁手机

2. 使用插件设置提供的 URL 重新加载插件

   • 使用侧边栏菜单（“汉堡包”图标）离开仪表板并返回
   • 注销并重新登录
   • 完全关闭应用程序

3. 使用之前加载的 URL 重新加载插件

   • 水平/垂直旋转屏幕
   • 选择仪表板项目（例如转移），然后“返回”导航至仪表板

类型 2 中的操作将成功加载插件，无论应用程序打开后已经过了多长时间。然而，类型3更复杂。它似乎在第一次完全验证后重新使用它“最终”到达的任何 URL。例如，当它首次加载（已完成身份验证）时，它将“最终”到达包含身份验证代码 A 的 URL。如果使用类型 3 操作重新加载，应用程序将向包含代码的 URL 发送请求A. 根据 OAuth 设计，它将无法进行身份验证，我们的插件将重新初始化身份验证过程 - 最终重定向到带有身份验证代码的新 URL B. 如果再次通过类型 3 操作刷新，应用程序仍会发送请求包含身份验证代码 A 的 URL，而不是最近使用的具有身份验证代码 B 的 URL。看来，无论执行类型 3 刷新多少次并且插件创建新的重定向，应用程序仍将使用该 URL它在第一次加载时就“结束”了。

这种情况仍然会导致插件身份验证成功，但当前的问题是类型 3 刷新将无法在一定时间范围后完成重新身份验证。如上所述，大约 10 多分钟后，当重定向到身份验证服务器时，应用程序将不会自动对用户进行身份验证，而是将 Banno 登录屏幕留在插件窗口内。

我能想到的解决此问题的唯一解决方案是确保初始身份验证“结束”于可用于无限期显示插件内容的 URL。这意味着建立一个单独的系统来验证类型 3 操作后来自应用程序的请求是否是显示客户信息的有效请求。任何有关如何处理这种情况的建议将不胜感激。

Banno Apps 中的插件是嵌入式 Web 应用程序。在 Banno Online 中，这是一个 iframe，在 Banno Mobile 中，这是一个嵌入式 webview。虽然这两种情况略有不同，但您描述的问题仍然相同。

插件页面可以随时刷新。没有办法阻止这种行为。编写良好的插件将在这些刷新之间保持其状态，以便用户甚至不会注意到。

保持页面状态的一部分是保持身份验证数据。用于初始验证用户身份的 OAuth 流程并不打算在每次页面刷新时使用。嵌入式 Web 应用程序预计将保持其自己的身份验证状态。如何完成此操作通常取决于嵌入式 Web 应用程序所使用的语言和平台。然而，所有策略几乎都使用 cookie，该 cookie 在应用程序关闭时会被销毁。

由于用于初始 OAuth 切换的身份验证在一段时间后过期，因此此时进一步尝试利用 OAuth 流程确实会向用户显示登录页面。通过在应用程序中保留一个会话，并具有自己独特的超时时间，并通过用户活动延长该超时时间，这种情况很少会发生。

您必须决定身份验证 cookie 的有效期限。检测您的身份验证 cookie 是否已过期并向用户显示一个特殊的错误页面，要求他们重新加载应用程序可能是值得的。

我能想到的解决此问题的唯一解决方案是确保初始身份验证“结束”于可用于无限期显示插件内容的 URL。这意味着建立一个单独的系统来验证类型 3 操作后来自应用程序的请求是否是显示客户信息的有效请求。

你在这里完全正确。一旦将代码交换为访问令牌，就应该重定向带有身份验证代码的 Oauth 回调 URL。从那时起，您的应用程序应该使用自己的身份验证机制。