Login Sessions Expiring after 5 Minutes of Inactivity

dev support
1

The issue we are having has to do with inactivity and session length. If you are active on the Website after logging in, you will have no issues. If you are inactive for 5 minutes or more, you are logged out and kicked to the login page. The session seems to only last for 5 minutes of inactivity. We desire to have our sessions last for 6 hours per the settings (see 2 examples below). Our production server is on ColdFusion MX7 and is using the exact same code and works as expected.

Can you think of any reason why our sessions would consistently expire after 5 minutes of inactivity since our session variables are being stored properly in the tables (see attached image)? Why 5 minutes?

Is there a test we can run or CFDUMP we could display to screen that would help us debug this?

=======================================================

We pass/display our CFID and CFTOKEN values within the URL of every page. For Lucee, the CFTOKEN value is always “0”.

CFREG is the name of the datasource we have created to store session and client information for login sessions. (CFMX 7 Production obviously uses the CGLOBAL/CDATA tables – different from what Lucee is using.)

=======================================================

After logging in, we check the CF_SESSION_DATA table and the CF_CLIENT_DATA tables to find our current CFID value (that is in the URL). The 2nd to last column is the EXPIRES column. The value in that column matches the hours values that we have set for session and client respectively. When we refresh our Website, the values update accordingly. After timing out, the values stay in the 2 respective tables.

======================================================

Here are the session/client settings on our Application.cfm page.

=======================================================

See attached image. Those are the SCOPE settings within Lucee Administrator.

Lucee_213_Scope
Lucee_213_Scope709×804 114 KB

=============================================================

=============================================================

An Example:

Say I am logged in and I click around and sit on this page:

pageName.cfm?CFID=3a8b284b-1d92-459e-a141-2686c7e6aa21&CFTOKEN=0

CLIENT SCOPE:
cfid
string 3a8b284b-1d92-459e-a141-2686c7e6aa21
cftoken
string 0
hitcount
number 5
lastvisit
Date Time (America/Chicago)
{ts ‘2021-09-03 10:53:42’}
timecreated
Date Time (America/Chicago)
{ts ‘2021-09-03 10:53:04’}
urltoken
string CFID=3a8b284b-1d92-459e-a141-2686c7e6aa21&CFTOKEN=0

5 Minutes later, I click a link on that page and am immediately kicked to the login screen. Here is the path in the browser:

pageName.cfm?CFID=3a8b284b-1d92-459e-a141-2686c7e6aa21&CFTOKEN=0

CLIENT SCOPE:
cfid
string 94e5c571-de39-4e8c-aba8-201ec370fcc6
cftoken
string 0
hitcount
number 1
lastvisit
Date Time (America/Chicago)
{ts ‘2021-09-03 11:04:12’}
timecreated
Date Time (America/Chicago)
{ts ‘2021-09-03 11:04:12’}
urltoken
string CFID=94e5c571-de39-4e8c-aba8-201ec370fcc6&CFTOKEN=0

If you notice that the URL string in the Web address stayed the same as the original, but the CFID and URLTOKEN values changed (within the Client Scope) to a new value somehow. Even though I have a valid CFID value (exists in the database tables – cf_session_data & cf_client_data – and has not expired), it doesn’t match up to the client scope – so I am kicked to the LOGIN screen. Both the new and the old CFID values exist in the tables and are not expired.

Any ideas why my CLIENT SCOPE is expiring/changing after 5 minutes?

Don’t forget to tell us about your stack!

OS: Linux (3.10.0-1160.36.2.el7.x86_64) 64bit
Java Version: 1.8.0_131 (Oracle Corporation) 64bit
Tomcat Version: Apache Tomcat/8.5.14
Lucee Version: Lucee 5.3.9.4-SNAPSHOT

2

not sure what the issue is, but you really shouldn’t be passing the CFID/TOKEN in every URL, leave it to the cookies

3

Beyond Zack’s comment, I’d ask also, Fred:

  • Are you tracking your logins via session vars or client vars? It’s not clear. You mention both scopes. Most would track logins via session vars, since their timeouts can indeed be set to days/hour/mins/secs.
  • You say your code ran on CF, and it only allowed client var durations of days (unlike Lucee, which offers the same days/hours/mins/secs for them), so I suspect you are relying on session vars. As such, you may help yourself to dump also the session scope, to see what it may show.
  • And indeed I’d recommend you dump the cookie scope, since those are key to how session and client scopes are managed, as Zack noted.
  • As important, when trying to sort out problems like this, dump the cgi.http_cookie value. This shows what cookies and values CAME INTO a request, whereas dumping the cookie scope could show cookies/values added or modified by your code or by the CFML engine, before that point in the request.
  • Perhaps still more important: you also show us only the Lucee admin, but can you show any code in application.cfm/cfc related to session and client mgt, if you have that? That would override the admin settings, of course. And while you may feel that can’t be a factor since “it worked on CF”, note that sometimes some CFML condition or tag/function may have a different result in ANY CFML engine, compared to an earlier version or different engine. So do be careful trusting your eyeballs in assessing flow of control. Sometimes throwing in log lines or dumps can help detect the unexpected.
  • Indeed, here’s something else that may help: dump the getapplicationmetadata() function, which in both CF engines would show what the CURRENT values of various application-level settings are, at that point in the code (so could reflect how app-level changes did or maybe did NOT take effect)

I appreciate that your focus is on where the bug is in Lucee that must be making your sessions timeout at 5 mins. It may seem “obvious” from your observations that it must be the cause. But doing troubleshooting as I do, I’ve simply learned that it’s best to get diagnostic evidence to confirm our suspicions. :slight_smile:

Sorry for the wall of words, but hope it may be helpful.

4

I realize that we shouldn’t be passing the CFID/CFTOKEN in the URL. This is a legacy Website that we are trying to get off CFMX and on to Lucee. Later on, I was going to work on an alternate login storage method. We are just trying to shut down an old box as quickly as possible.

Here is the information from our Application.cfm page (I thought I had originally pasted that, so sorry.):

Upon logging in, the CFID that is generated is stored within the CF_SESSION_DATA table. The same CFID is ALSO stored within the CF_CLIENT_DATA table. The expiration times coincide with the number of hours set on the Application.cfm page and/or within Lucee Administrator scope.

================================================
I examined the COOKIE scope previously. I only saw one cookie named “USER_ID”. The value for this is the userID that the user used for their credentials to login.

The SESSION scope is very similar to the CLIENT scope. See below:

SESSION SCOPE:

cfid string 552072d1-5fd2-43e4-8073-b4c5b124e275
cftoken string 0
lastvisit Date Time (America/Chicago)
{ts ‘2021-09-03 18:30:31’}
sessionid string _552072d1-5fd2-43e4-8073-b4c5b124e275_0
timecreated Date Time (America/Chicago)
{ts ‘2021-09-03 18:30:30’}
urltoken string CFID=552072d1-5fd2-43e4-8073-b4c5b124e275&CFTOKEN=0

CLIENT SCOPE:

cfid string 552072d1-5fd2-43e4-8073-b4c5b124e275
cftoken string 0
hitcount number 3
lastvisit Date Time (America/Chicago)
{ts ‘2021-09-03 18:30:31’}
timecreated Date Time (America/Chicago)
{ts ‘2021-09-03 18:30:30’}
urltoken string CFID=552072d1-5fd2-43e4-8073-b4c5b124e275&CFTOKEN=0

SESSION SCOPE (after 5 minutes and getting kicked to the Login screen):

cfid string 293ba513-b823-487e-95cb-1d172b602216
cftoken string 0
lastvisit Date Time (America/Chicago)
{ts ‘2021-09-03 18:41:27’}
sessionid string _293ba513-b823-487e-95cb-1d172b602216_0
timecreated Date Time (America/Chicago)
{ts ‘2021-09-03 18:41:27’}
urltoken string CFID=293ba513-b823-487e-95cb-1d172b602216&CFTOKEN=0

After 5 minutes, the CFID value within session and client scope both change to the same values but different from the original (and the value showing in the URL).

===========================================================
CGI.http_cookie value = USER_ID=FSurber

==========================================================

I will do a comparison of the Applicaton MetaData values for both cases and report back to you what differences I find.

I’m still not seeing where the 5 minutes is coming from. I don’t see it as a setting. I’m wondering if it is some type of inherent default value.

Thanks for your help.

5

Here is the dump of the getApplicationMetaData(). There were no differences between the pre and post page renderings. Let me know if this is clear or if a screen capture would be better.

Struct (ordered)
Entries: 46
applicationTimeout
Timespan createTimeSpan(20,0,0,0)
blockedExtForFileUpload
Empty:null
clientManagement
boolean true
clientStorage
string cfreg
sessionStorage
string cfreg
customTagPaths
Array
componentPaths
Array
loginStorage
string cookie
mappings
Struct (ordered)
name
string
scriptProtect
string all
secureJson
boolean false
CGIReadOnly
boolean true
typeChecking
boolean true
secureJsonPrefix
string //
sessionManagement
boolean true
sessionTimeout
Timespan createTimeSpan(0,6,0,0)
clientTimeout
Timespan createTimeSpan(0,5,0,0)
setClientCookies
boolean false
setDomainCookies
boolean false
localMode
boolean false
locale
string en_US
timezone
string America/Chicago
nullSupport
boolean false
enableNullSupport
boolean false
scopeCascading
string standard
searchImplicitScopes
boolean true
charset
Struct (ordered)
web
string UTF-8
resource
string UTF-8
sessionType
string application
serverSideFormValidation
boolean false
clientCluster
boolean false
sessionCluster
boolean false
invokeImplicitAccessor
boolean false
triggerDataMember
boolean false
sameformfieldsasarray
boolean false
sameurlfieldsasarray
boolean false
datasource
string
defaultDatasource
string
s3
Struct
accessKeyId
Empty:null
awsSecretKey
Empty:null
defaultLocation
Empty:null
host
string s3.amazonaws.com
wssettings
Struct (ordered)
type
string Axis1
query
Struct (ordered)
varusage
string ignore
psq
boolean false
datasources
Struct (ordered)
logs
Struct (ordered)
mails
Array
serialization
Struct
preserveCaseForQueryColumn
boolean true
preserveCaseForStructKey
boolean true
serializeQueryAs
string row
javaSettings
Struct (ordered)
loadCFMLClassPath
string
reloadOnChange
boolean false
watchInterval
number 60
watchExtensions
string jar,class

6

Somehow your issue reminds me of a similar situation that I had when I switched an old legacy app…

If my brain isn’t telling me something wrong, old legacy Coldfusion engines ALWAYS set cookies for cfid/cftoken: As soon as you’ve enabled session management, that legacy cfengine would always create cookies for cftoken/cfid automatically, even with client cookies disabled. Back then cookie creation even couldn’t be turned totally off (!!!) easily.

At that time urltokens (cfid/cftoken in url) pratically lived in parallel along with the cookies cftoken/cfid. Urltoken was just some kind of fallback in case cookies didn’t work in the browser. Some tags even added urltokens by default (e.g. cflocation which as of today is a bad security practice as commented by @Zackster) . I’m pretty (but not totally) sure that is how your cfmx7 still works.

Seeing from the screenshot of your Lucee admin setting I can clearly see that you have client cookies disabled. That setting in Lucee turns cookie creation for cftoken/cfid totally off (which differs from legacy cfengines). Search and look for the reference of the application setclientcookies directive here.

Quote from the docs application.setclientcookies

If you set this attribute to"No", Lucee does not automatically send the CFID and CFTOKEN cookies to the client browser; you must manually code CFID and CFTOKEN on the URL for every page that uses Session or Client variables.

If your legacy app was developed on a legacy cfengine, your cookies for cftoken/cfid would always be available everywhere, which now might be missing on Lucee, and maybe your apps code does some checks with those cookies.

Here are the steps I’d take to verify this:

  1. Step: dump the cgi.http_cookie value as @carehart mentioned, but from within the app running cfmx7 and look if cftoken/cfid cookies are present there. If these are present there, they will be probably missing when running on Lucee. Then proceed with next step.

  2. Step: For testing, enable the “client cookies” in the Lucee admin and make sure the cookies for cfid/cftoken are being set by dumping cgi.http_cookie on your app running with Lucee

  3. Step: If the above steps resolve your issue, decide how you want to set the session cookies. You may let client cookies enabled and make use of the application
    struct sessioncookie. Alternatively, set the cookies for cftoken and cfid in your apps with cfcookie.

Let us know about your progress!

7

Yep, Andreas. I wasn’t as sure about that admin setting in Lucee. I suspected it could be key. Cf has a similar one.

And as for your concluding point, I’d add that if enabling that solved this, but one might want to solve at the app level instead, one could use setclientcookies in the this scope of an application.cfc, or as an attribute of cfapplication.

As for the sessioncookie property/attribute, that’s for controlling more specific aspects of those cookies (like httponly, secure, etc.).

Hope that’s helpful. Always open to correction, especially regarding differences in Lucee that I may miss or misrepresent.

8

BTW Fred, I don’t see that your second attempt to include your application.cfc or cfm made it here. I’d been waiting to see that before replying, as in fact I’d wanted to see if you did or did not use that setclientcookies=“true” (or “yes”) as just mentioned.

If you had–and yet no cookies were being set, that would have been a different issue and path for us to take.

9

Very strange. I have copied and pasted the code from the application.cfm page twice. It does not show up in the posting. I took a screen cap…here:

application216

10

OK, I dumped the HTTP_cookie.

On production, there are 4 total cookies: USER_ID, SHOWCLEARED, UNASSIGNED, and “ga”

_ga=GA1.2.1773057785.1596558130
SHOWCLEARED=1
UNASSIGNED=0
USER_ID=FSurber

Do you know what “_ga” would be?

I haven’t mentioned, but we have a legacy backup website which is running BlueDragon. It has always worked just fine, and has not experienced the timeout issue due to inactivity. I dumped the HTTP_cookie on this BD site. It only had the one cookie.

USER_ID=FSurber

11

Strange, indeed. First, let me address your issue with posting code, then with your ongoing issue of logins expiring too soon for you.

The text editor here suggests you can use HTML and CFML freely, but something that can help readers is when you use the “preformatted text” button in the text editor here, as I have done here with your code:

<cfapplication name="CorporateCarNet"
clientmanagement="Yes"
sessionmanagement="Yes" 
clientstorage="CFREG"
setclientcookies="No"
applicationtimeout="#CreateTimeSpan(20,0,0,0)#" 
sessiontimeout="#CreateTimeSpan(0,5,0,0)#"
>

So anyway, yep, we see you have setclientcookies=“no”. That at least explains why you have no cfid/cftoken cookies. And yet that should have been true for you in CF as well, so it would seem odd then if it worked without cookies–but Andreas is recalling that perhaps in CF7 there was an issue where it DID always create them, regardless. I don’t recall that, but it’s possible.

And as he and I have said, if you setclientcookies to yes, that may help you–with that at least.

But your focus from the outset has been on why your sessions are timing out after only 5 mins. Let’s see if perhaps using the client cookies may help.

If not, I had asked more questions in my first reply (to perhaps drive us to an understanding) that you have not answered, and those may help.

For example, and perhaps most important, are you relying on session vars or client vars for tracking the login? It can’t be that in CF (any version) you used client vars to track logins, as they don’t have a timeout in minuotes or seconds (only Lucee adds that…I don’t think even BlueDragon did).

You also talk about querying the database tables, naming those that Lucee uses. It’s not clear if you mean you are doing that for diagnostic purposes or that you do it in your code (as part of the login check). If so, then again that can’t have been how you did things in CF (since again client vars would “timeout” only in terms of days of inactivity).

Perhaps rather than show only this cfapplication, it may be useful for you to share the code doing the login check…which may be easier now if my approach above for posting code works for you. But maybe you can just confirm in words what you are doing.

As always, just trying to help–even if it means raising more questions than answers.

1 Like
12

That looks like a Google Analytics cookie.

13

I’d recommend always test this stuff using curl, or in a fresh incognito / private browsing session

14

So I set “setClientCookies” equal to “Yes” as suggested. I also went into Lucee Admin and double-checked the timeout values. I also made sure that Domain Cookies and Client Cookies were checked. I rebooted Lucee.

Upon logging in, I have the following cookies now:

–USER_ID (same as before)
–cfid (with valid value)
–CFID (blank)
–cftoken (0 value, of course)
–CFTOKEN (blank)

I’m not sure why I am getting both an Uppercase and a Lowercase version of the Cfid/CfToken cookies. By the way, my URL string has CFID & CFTOKEN in it.

This is working. My session does not timeout (so far after 20 minutes). I’m guessing this is working because of the client cookies. I assume the client cookies will timeout according to the value of “Client Timeout” in Lucee Administrator.(currently 5 hours).

My goal was to fix the issue so that it worked off the CFID/CFTOKEN values passed in the URL. I am pretty certain the reason it is working now is because of the cfid/cftoken values passed in the cookies.

I guess I can get rid of passing the CFID/CFTOKEN in the URL. (This is a legacy site that I inherited. I’m not sure why it was done this way.)

My only concern now is … should I be worried about having 2 versions of Cfid (cfid & CFID) and 2 versions of Cftoken (cftoken & CFTOKEN) ?? Is there something I can do to get rid of the UpperCase versions?

15

This is something I also discovered in the past. These cookies are possibly being created by cfcookie. See:

https://luceeserver.atlassian.net/browse/LDEV-2466

If you are using setClientCookies=true they will be created in lower case, while cfcookie creates them in upper case.

This also tells me that you are very likely using cfcookie, and in that logic there will be your issue about the 5min expiration.

16

And FWIW, that case conversion can be preserved with cfcookie’s preservecase=“true” (introduced in cf10 and supported by Lucee).

But beware there could be other differences in the cookies created by the engine’s app framework and cfcookie, which could lead to such dupes, including the domain, and others like the httponly and secure attributes of a cookie. And these can be confirmed at the cfcookie or application level.

And Fred, note that you may well have hit similar problems of dupe cfid/cftoken cookies if you’d moved instead from your cf7 to cf10 or above.

Looking forward to hearing what ultimately was causing your 5 min timeout, if it’s ever discerned.

1 Like
17

@carehart thank you very much for that informative post. I wasn’t aware that/when the preservecase attribute was introduced to cfcookie. Something I’ve totally missed. Because it’s up to us developers to create the cfcookie correctly manually, it’s also up to us to create them with the correct names (cftoken/cfid in lower case), what now can be done with the preservecase. That makes the jira bug I’ve filed practically unnecessary and worthless. In my opinion this ticket can be closed. Going to comment it there now.