在Coldfusion中使用多个SessionTimeout

我有一个应用程序，它有不同类型的用户。我需要根据用户类型设置sessionTimeout。例如，管理员30分钟，用户10分钟。为此，我在application.cfc中提供了一个默认的sessionTimeout 30分钟

<cfcomponent output="false" extends="org.corfield.framework">   
    <cfset this.applicationTimeout = createTimeSpan(1,0,0,0) />
    <cfset this.sessionManagement = true />
    <cfset this.sessionTimeout = createTimeSpan(0,0,30,0) />
    .............
    ............

</cfcomponent>

.............
............

当我转储应用程序变量时，我可以看到sessionTimeout是600，这是正确的。现在在onRequestStart方法中，我编写了一个代码来检查loggedIn用户类型并相应地设置sessionTimeout

<cfif StructKeyExists(session,"user") AND ListLast(CGI.HTTP_REFERER,"/") EQ "login.cfm" >
    <cfif session.user.userType EQ "GSA">
        <cfset this.sessionTimeout = createTimeSpan(0,0,10,0) />
    </cfif>
</cfif>

在此之后，当我转储应用程序变量时，sessionTimeout以天而不是秒显示。而且10分钟后会议也不会结束。

---

有人能帮忙吗？如何在应用程序中实现两种不同的sessionTimeout？还有为什么我再次设置sessionTimeout时，它会以天而不是秒显示sessionTimeout？

会话超时对于所有用户来说都很常见。当第一个请求出现时，超时持续时间在应用程序范围内设置

---

我认为简单的答案是，您不能设置两个不同的会话超时持续时间。

我不认为有任何方法可以从以下函数之一内部修改

此

范围元数据：

onApplicationStart

，

onSessionStart

或

onRequestStart

。这意味着您不能在任何这些方法中设置

this.sessionTimeout

我最近在调查这件事。但是，元数据是为ColdFusion发出的每个请求设置的。这意味着您可以尝试Ben Nadel在本文中提到的方法，将设置超时的逻辑移出

onRequest（）

并移至

this

范围，然后尝试创建动态会话超时

---

不过，您可能需要创造性地弄清楚此时哪个用户正在登录。（即使稍后发生身份验证…设置超时是否有任何危害？

以下是一种可以使用的方法。这有点像是创建您自己的会话管理客户端，但它允许每个用户角色自定义会话超时。 在会话范围中创建时间戳，该时间戳最初设置为用户登录到应用程序的当前时间。在应用程序的客户端JavaScript中，创建一个计时器，每隔一分钟左右调用一个函数，然后依次调用服务器端函数，以查看自上次记录该用户的时间戳以来经过了多少时间。如果经过的时间达到该用户角色允许的最大值，请使用JavaScript函数注销该用户。

---

使用此方法，您可以在用户每次与应用程序“交互”（运行脚本、调用cfc库函数等）时重置时间戳，以便用户在积极使用应用程序时不会注销。用户只有在您定义的“x”分钟不活动后才能注销，并且您在服务器端调用的函数可以进一步定义每个用户角色的数量

我在railo中使用过这个，但我认为它也适用于coldfusion

getPageContext().getSession().setMaxInactiveInterval(javaCast("int", 60));

---

它基本上将当前正在运行的请求的会话超时值设置为60左右（我不记得是在几分钟还是几秒钟内）

为了实现这一点，我可以做些什么调整吗？一个非常可怕的方法是在

会话

范围内设置一个变量，并在每个请求中测试和更新该变量。然后，您必须构建自己的会话检查。OT：当我被要求构建一些使系统性能下降的东西时，我通常会后退。你想要保护的是什么？这应该如何解决你认为可能存在的任何问题？这是客户的要求，我试图找到任何解决方案，否则我可以说服他们。我知道你使用的是FW/1。如果在

application.cfc中以一种或另一种方式处理所有的安全性，那么您就处于良好状态，这将有一个LOE。OTHH，您必须考虑到会话 S可以从CF的观点来看是好的，但是从您的业务逻辑观点来看是无效的。