0

这实际上可能不是 Identity Server 或 oidc-client 的问题，但我无法确定问题。我在 Aurelia 应用程序中通过 System.js 运行它，因此问题可能源自这些外部库之一。

在CheckSessionIFrame.start(session_state)中，我们有以下代码：

this._timer = window.setInterval(() => {
  this._frame.contentWindow.postMessage(this._client_id + " " + this._session_state, this._frame_origin);
}, this._interval);

间隔第一次触发时，似乎没有问题。iFrame 的 contentWindow 存在（如预期的那样）并且 postMessage 方法被调用而没有问题。两秒钟后，当间隔再次触发时，this._frame.contentWindow未定义 - 所以我最好的猜测是 iFrame 以某种方式死亡。同样，这可能不是 oidc-client 的问题，但我正在寻找任何可能导致此 iFrame 死机的有用指导（可能在内部它可能在脚本上死机？）例如缺少必要的配置值oidc 客户端。

4

1 回答 1

1

要使 oidc-client 与静默更新一起工作，您需要将 aurelia-app 放在一个不是 body 的元素上，这样您就可以将元素放置在 body 内但在 aurelia-app 之外。

这允许您将 IFrame 放在 aurelia-app 之外，从而防止 Aurelia 引导程序吃掉它并让 oidc-client 独立于 Aurelia 运行。

编辑

根据您的评论，以及我的一点记忆，我重新措辞/澄清：

会话检查器和静默更新功能彼此独立工作。您可以在会话检查器通过手动调用启动之前静默续订。您也可以在不执行任何静默更新的情况下启动会话检查器。它们只是方便一起使用，但这是它们唯一的关系。

我假设您使用混合流程并使用 RP 和 OP iframe 实现标准会话检查器，其中 OP iframe 在check_session.html页面中，而 RP iframe 在您的 aurelia 应用程序中的某个位置。在我的一个项目中，我在index.htmlaurelia-app 元素之外有 RP iframe，因此它独立于 aurelia 工作。但我想它不一定必须在那里。

当您将srcRP iframe 的属性设置为您的check_session.html的位置时，会话检查器将启动session_state，check_session_iframe并client_id在哈希之后。

check_session.html页面将通过启动定期轮询来响应该请求，并在状态发生更改时将消息发回window您的 aurelia 应用程序。

从您的 aurelia 应用程序中，您可以收听该消息并在signinSilent()它指示状态更改时进行呼叫。在silent_renew.html页面中，您可以使用signinSilentCallback()

所有这些都到位了，当你启动会话检查器时真的没关系。把它藏在某处的某个功能中，最后加载该功能。

在应用程序启动期间，您需要担心的唯一两件事是：

  • 检查是否开始window.hash并#code调用signinRedirectCallback(code)
  • 如果没有，请signinSilent()立即致电（这样您要检查的事情最少）

然后在完成其中任何一个之后，getUser()检查它是否为空或expired属性 === true。如果是其中任何一种情况，请执行signinRedirect(). 如果没有，您的用户已通过身份验证，您可以让 aurelia 应用程序执行此操作并启动会话检查器等。

我绝对不会在 aurelia-app 中对您的 index.html 进行初始身份验证检查。因为如果 aurelia 恰好在 oidc 检查完成之前完成加载，则该过程将失败。您可能还希望将用户对象（和 UserManager）存储在某些缓存/服务/其他类型的单例类中，以便您可以轻松地从您的 aurelia 应用程序与 oidc 交互。

于 2016-09-28T14:26:43.563 回答