0

我在 MobileFirst 7.1 中遇到了一个奇怪的情况,用户偶尔无法进行身份验证/登录。出现问题的唯一迹象是 console.log 中的一条消息

[审核] CWWKS1100A:用户 ID 的身份验证未成功。指定了无效的用户 ID 或密码。

我的自定义登录模块使用com.worklight.core.auth.ext.LdapLoginModule(为了澄清我有一个使用 LDAP 进行身份验证的登录模块)。就像我说的那样,大多数时候一切似乎都可以正常工作,但有时用户最终会遇到无法进行身份验证的情况。我怀疑它可能以某种方式与会话有关,但这只是基于我的调查的猜测。

我已经向我的“秘密”适配器添加了一些日志记录,它将会话状态打印到console log,显然这出现在logs上面失败的身份验证消息之前,但它是空的,即。会话不包含任何内容。此时用户显然正在尝试访问安全适配器,并且由于他们没有经过身份验证,他们最终进入了登录页面(我也应该说基于表单的身份验证)。

无论如何,我注意到虽然似乎没有会话数据,但 jsessionid 在那里并且没有改变,即即使我刷新浏览器它也不会改变。当然,这本身可能不是问题,但有趣的是,如果我删除此条目并刷新我的浏览器,我就能成功登录。

我很确定我的处理程序代码success/failure在正确的位置调用了相关方法,但是当然没有什么可以阻止用户刷新他们的浏览器,这会导致他们被重定向到登录页面(该应用程序是使用 AngularJS 开发的单页导航模型也是如此)。

我能想到的唯一可重现的测试是当我登录到 MobileFirst 控制台,然后尝试登录到我们的 MF 'desktopbrowser' 应用程序时。我已经读到这种情况会导致与会话相关的冲突,但正如我所说,我看到的偶尔出现的问题并不是由此引起的(尽管它可能是相关的)。

4

1 回答 1

0

所以这个问题似乎更多地与成功登录后我们应用程序中的逻辑流有关,而不是 MF 平台的任何固有问题。

例如,当用户刷新浏览器时,他们实际上仍处于登录状态,但由于应用程序(基于我们开发的逻辑)在刷新时将用户带到登录页面,因此用户实际上是重新登录到同一个会话。如果每次都失败,当然会更容易查明,但事实并非如此。解决方案是在刷新时强制注销(当应用程序初始化时),从而清除所有会话数据。在未来的迭代中,刷新后基于经过身份验证的会话重新建立应用程序当然会更好,但目前这一步太远了。

另一个例子是登录后,如果随后的适配器调用失败(例如,我们验证然后从数据库中检索配置文件数据),那么我们也没有将成功验证的用户注销。

于 2016-03-08T10:00:41.557 回答