I’ve got an app that I’ve used for a while, a few years maybe. At successful login within the cflogin body I establish a session.user variable that I use throughout the app to determine if someone should still be logged in.
In the last few months when I first go to the directory where my app is located I get a session.user.id doesn’t exist error. The error results from index.cfm. What doesn’t make sense to me is why it’s looking there in the first place. Application.cfc should be looking at the initial request to the app and see that cfloginuser hasn’t been initiated, run the code in cflogin which calls for a login page and only if there is a successful login entry would it then run the code in index.cfm.
To top this off if I refresh the page where I get the initial error, the error goes away.
Anyone have something go wonky like this with there session variables, or have any suggestions on how I might fix the issues that I have happening?
Also if you need further description of the issue, code base, whatever. Let me know.
Version Lucee 6.0.0.572-RC
Version Name [Gelert]
Release date Oct 2, 2023
Loader Version 6.0.0.519-RC
Servlet Container Apache Tomcat/9.0.80
Java 20.0.2 (Homebrew) 64bit
OS Mac OS X (14.0) 64bit
Architecture 64bit
There can of course be many reasons that such session snd/of cflogin oddities arise, but let’s start with one I’d consider based on what you’ve said so far:
Does your application.cfc have any cflock tags or lock cfscript statements? By that I mean first in any way around the cflogin (even if not IMMEDIATELY surrounding it), then around any code having to do with managing sessions (in onsession or otherwise)?
I ask because the variability of something only “sometimes failing” has a smell, like it’s that such lock code may be having contention (with other requests holding the needed lock)–which can happen for various reasons having nothing on the surface to do with this request that’s “not working”.
More to that point, does any such cflock/lock have throwontimeout set to false, no, or off? If so, that means a lock timeout would be ignored (and so no error would happen)–so that the code in the lock simply “wouldn’t run”. Finally, is the code wrapped in any try/catch where an error is being ignored? That too could mean some code (in the try) might unexpectedly “not run”.
All these have nothing specific to do with cflogin or sessions, but I’m saying they are the kind of things that can cause “odd, unexpected, seemingly unrepeatable behavior”, because the code may not be running just as you’d expect it to. It can really wreak havoc trying to debug such problems, if not considered.
Or perhaps someone else will offer very different suggestions for you.
I haven’t used the cflogin code since the early 2000’s, favoring my own patterns for authentication (see Authentication Guide CFML Documentation) and session management (see Session Management Guide CFML Documentation) that give me greater control over the process than cflogin did.
That said, while I can’t speak to the root cause without looking at the code, I will instead suggest an easy workaround… at the end of your onRequestStart() method in your Application.cfc (assuming this method is where the isUserLoggedIn() check happens) I would check for the existence of ‘user’ in session (!structKeyExists( session, ‘user’ ) || isNull( session.user)) and if its not found (or is null) then relocate the user to the login screen.
This should ensure that if, for whatever reason, isUserLoggedIn() returns true but session.user doesn’t exist or is null that it will force a login regardless and eliminate the chance of reaching index.cfm without the session.user.id data it needs.
Not an answer for ‘why’, but an easy add to be rid of the problem.
HTH
Edit: if all else fails or you’d really like to understand the root of the issue feel free to reach out to me in DMs on LinkedIn and I’d be happy to schedule a zoom meeting and help review the code with you.
— Denny
@ddspringle
@carehart
Hey guys thanks so much for the direction. I’ll look into the code base and see if any of those scenarios exists within it.
Lastly,
Check / ensure that all yuor variables are “scoped”.
We had some really peculiar errors - sometimes a page would work - other times not - and all without changing any code - for it to be finally worked out - that we had unscoped variables in play and that a previous request’s variables usage was effecting THIS request.