asp.net - 在 ASP.Net session 中持久化对象

Question

我正在开发一个 ASP.Net 应用程序(内部网)，它需要用户进行身份验证才能访问门户。

目前，我保存 Employee 对象进入 InProc session 状态 一旦认证成功。然后在 Master Page 的 PageLoad 方法中检查 Employee 的 Session 是否为空(null)，这意味着当前请求没有经过身份验证，然后我重定向到 Login 页面。

母版页页面加载:

if (Session["Employee"] == null) Response.Redirect("~/Login.aspx");

我还几乎在每个页面中都使用员工 session 来获取有关已登录员工或其权限级别等的一些详细信息。

我的问题:

上述技术是否可以很好地处理这种情况？

有时 Session 状态在服务器上被回收(丢失)，所以如果我在任何 的 PageLoad 中调用 Session 状态子页当 Session 为 null 时，它会抛出异常，因为检查 session 是否存在的 Master Page onLoad 方法仅在子页面 onLoad 方法之后运行。如何以及在哪里可以在统一的地方检查 session 是否存在？因为我不想每次访问 Session 状态时都检查 Session 是否存在。

session 结束后是否可以触发方法？我在 Global.asax 中尝试了 Session_End，但它不允许我调用任何方法或重定向到页面。

谢谢，

Answer 1

• Is the above technique is good to handle such scenario?

当然，“好”是主观的。但是这种情况应该没问题。有多种方法可以处理用户跟踪，我很好奇是否有人有任何具体建议。

• How and where can I check for the session existence in unified place?

我建议将用户跟踪的 Session 部分抽象为应用程序中的一个公共(public)对象。在该对象中，您将检查 Session 是否为空，检查用户是否已登录，做出相应的响应等。然后所有页面(子页面和主页面)都应该使用该对象。

这带来了几个好处:

您只需在一处编写 session 逻辑。因此，您不会在整个应用程序中不断地在 Session 上编写条件。应用程序的其余部分只是调用公共(public)对象上的方法。

如果您以后想将用户跟踪从 Session 转移到其他东西(例如数据库......我过去曾使用 RavenDB 和 MongoDB 之类的东西来跟踪 transient Web 应用程序数据并取得良好的效果)，您只需要换一个类。应用程序的其余部分仍然继续使用该公共(public)对象。

例如，这个类可能有这样的东西:

public static string GetCurrentUsername()
{
    if (Session["Employee"] == null)
        throw new SomeKindOfAuthenticationException();
    return ((EmployeeObject)Session["Employee"]).Username;
}

然后在整个应用程序中，您只需将用户跟踪对象调用为 GetCurrentUsername。 .在 Application_Error您可以通过重定向到登录页面来处理身份验证异常。 (这通常被认为比在上述方法中为未经身份验证的用户返回空字符串更好的做法。空字符串必须在整个应用程序中不断检查，而异常处理可能发生在一个地方。如果您需要特定页面在这种情况下不重定向到登录页面而只是不显示某些内容，请将调用包装在该页面本地的异常处理中并相应地处理它。)

当然，考虑到这主要是一个高级设计猜想，我并不是指我面前的实际实现。也许是 static将导致 Session 出现问题?也许你需要把它传递给 Session ?你应该在哪里存储这个类？您还应该进行哪些其他错误检查？等等。

• Is it possible to trigger a method once a session ends?

根据我的经验，不可靠。考虑 session 可能结束的所有方式。用户可以单击具有清除 session 逻辑的“注销”链接，或者他们可以放弃浏览器，或者他们的连接可能会在很长一段时间内失败，等等。Web 应用程序是被动请求/响应系统。在没有用户交互的情况下响应 session 超时相当于一个正在进行的服务器端进程，而 Web 应用程序不适合这样做。

这实际上是我尝试将这些 transient 数据存储在数据库中的原因之一。这样我就可以有一个单独的进程(例如 Windows 服务......旨在在没有用户请求的情况下在后台持续运行的东西)监视该数据库并相应地响应事物。在这种设置中可以完成的一件事是一种手动 Session_End。一个单独的进程将轮询数据库中未在 X 分钟内看到事件的 session (例如，通过检查事件跟踪记录上的时间戳)并通过清除相关数据和执行任何其他任务来响应。

在我看来，这相当清晰地将 Web 应用程序(响应用户请求)和状态跟踪(维护服务器端数据)的职责分开。