Question

I get an error message: "auth.USR_xID is undefined in Session" not quite repeatable but here and there. But the variable is defined in line 25, then used in line 77 and again in line 265 but here it throws an error - I'd say every 1,000th request of that page.

Line 25: <cfparam name="session.auth.USR_xID" default="#SESSION.auth.USR_ID#">
some more code
Line 77: <cfset USR_Pointer = "#SESSION.auth.USR_xID#">
some more code
Line 265: <cfif session.auth.usr_id IS session.auth.usr_xid>
...

We were trying to find similar cases but couldn't. We loaded the page, killed the session and then hit submit. Everything worked just fine. We were not able to reproduce the error but it happens. We have over 1 million users on it and 10+ transactions in any given second. Anybody having an idea?

Was it helpful?

Solution

@Derrick gave a good answer. Another possibility is when the user has two instances of your application open. Could be in two tabs or two browser windows. That could cause the two sessions to interfere with each other. It might even be possible for the session to time out in one tab which messes up the other.

OTHER TIPS

IF - IF - If this is a public facing site/page, most likely, it's due to a bot. I've found that bots may/may not be hung up on code in between - specifically between line 25 and 77 (or 265) the bot may get caught on something and since the bot usually won't hold session, it will generate an error. I screen for bots and assign a variable for the bot "user." If the user is a bot (per variable) then I do something else. Make sense? If this is NOT a public facing site, then I don't have an answer for you. But my own experience has been that it's always the bots that cause these types of errors, unless your user can "sit" on the page for X amount of time and then reload without being forced to re-initiate the session.

I agree with Dan, Having the application in multiple tabs is a really easy way to upset session state.

At my last job we wrote a Patient management system. A user would;

  • Login Go to patient A, in the current tab and do some "stuff".
  • Open a new tab - to do something in Patient B's record.
  • Return to Patient A's original tab and do further edits there.

But changes made on the patient A tab - were now being attributed to Patient B not patient A. (we store the patientid in the session scope - and were using; where patientid = "#session.patientid#" - in all of our queries.

We had to implement some JS trickery AND extra CFML code too, to try and combat this by appending the timestamp to session identifiers to ensure that they are unique within tabs.

Then, you need to code for keeping users authenticated / authorised - as a you now have a new session, not the same old one - It was a giant issue for us.

And it took us a really long time to get a handle on the cause and the fix for it, too.

Simply telling users not to use multiple tabs - wasn't a workable solution for us either - so we were stuck with finding a technical solution.

Despite no longer working there - I could probably attain the portion of code that we used for this work, if you want to review it?

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top