5

我们看到 DNN 中没有放弃会话的问题。我不确定这是否是 4.5.x 问题，因为我们不久前升级到 5.x 并且可能引用了旧控件。

我们在模块中引用的登录/注销控件是 DotNetNuke.UI.Skins.Controls.Login，位于路径 DNN_Web_Root/admin/Skins/login.ascx

在那里，它看起来像重定向到 logoff.aspx，然后通过 LogoffHttpHandler，然后去某个地方完成注销过程但是我找不到该过程在哪里查看是否正在调用 Session.Abandon。

任何人都可以回答以下问题：

  • DNN 是否存在在注销时未调用 Session.Abandon 的问题？
  • 实际处理 LogOff 进程的进程是什么？
4

3 回答 3

2

注销通常由 Desktopmodules\Admin\Authentication\Logoff.ascx 处理。主要操作是清除身份验证 cookie，以及一些其他 cookie 和一些用户特定的缓存数据。

DotNetNuke 从不将 Session 用于任何事情，并且在注销期间不会清除 Session。

于 2011-06-06T16:59:18.213 回答
0

看起来 Dan Rowe 对以下代码有一些运气：

Response.Redirect(Globals.NavigateURL(TTSRoutines.giPunchinPage, "Logoff"), True)

参考

于 2011-06-05T05:09:00.250 回答
0

我假设您担心的威胁是共享计算机环境场景，其中有人注销但没有关闭浏览器，下一个用户坐下来并能够访问他们不应该访问的东西，因为会话变量仍然存在20分钟左右？

如果您必须使用会话，一种解决方法是简单地检查

System.Web.HttpContext.Current.User.Identity.IsAuthenticated

在任何地方，您都担心未登录的用户会利用先前登录的用户会话变量。

话虽这么说 - 按照@ScottS 的建议在 Logoff 中调用 Session.Abandon() 可能是最简单的方法，尽管此选项在托管环境中可能不可用。

于 2016-01-05T20:51:07.323 回答