How can a session variable definition "evaporate" within a Coldfusion page? - session

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?

#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.

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?

Related

Flow Triggering Itself(Possibly), Each run hits past IDs that were edited

I am pretty new to power automate. I created a flow that triggers when an item is created or modified. It initializes some variables and then does some switch cases to assign values to each of them. The variables then go into an array and another variable is incremented to get the total of the array. I then have a conditional to assign a value to a column in the list. I tested the flow specifically going into the modern view of the list and clicking the save button. This worked a bunch of times and I sent it for user testing. One of the users edited multiple items by double clicking into the item which saves after each column change(which I assume triggers a run of the flow)
The flow seemingly works but seemed to get bogged down at a point based on run history. I let it sit overnight and then tested again and now it shows runs from multiple IDs at a time even though I only edited one specific one.
I had another developer take a look at my flow and he could not spot anything wrong with it and it never had a hard error in testing only warnings about conditionals causing a loop but all my conditionals rectify. Pictures included. I am just not sure of any caveats I might be missing.
I am currently letting the flow sit to see if it finishes getting caught up. I read about the concurrent run option as well as conditions on the trigger itself. I am curious as to why it seems to run on two records(or more) all at once without me or anyone editing each one.
You might be able to ignore the updates from the service account/account which is used in the connection of the actions by using the following trigger condition expression:
#not(equals(triggerOutputs()?['body/Editor/Claims'], 'i:0#.f|membership|johndoe#contoso.onmicrosoft.com'))

Community-auth Codeigniter 3 - randomly seems to lose session variable

I am using Community-Auth with Codeingniter V3 to do authentication and to store authorization levels, etc.
The problem I am having is that my users are sometimes being redirected to the login page, even though they have not been inactive. I cannot seem to isolate a particular behavior or pattern to duplicate the problem.
The problem occurs when a controller calls the verify_min_level routine which should just verify that they are logged on. But it returns FALSE, which means Community-Auth believes they are not logged in, and the code redirects to the login screen.
Since it seems to happen randomly and for no apparent reason (the user was not inactive for a while, etc) it is driving my users crazy.
Has anyone else seen this kind of behavior?
I seem to have identified the problem. This particular client wanted sessions that would only end when they logged out or closed their browser window. So I set the session expiration to zero (0).
I thought that the garbage collection would only delete sessions occasionally (given that in codeigniter I understand that 0 means the session ends in two years) and that I would catch up with it with my own garbage collection. However I started noticing that the ci_sessions table (I moved session data to database from file system to help debug this issue) would have multiple sessions removed frequently, even though none of the sessions were anywhere near two years old.
What seems to have solved the problem is to turn off the garbage collection completely by setting the PHP parameter sessions.gc_probability to 0.
No garbage collection, no premature deletion of session variables.
I am implementing a nightly CRON job to do garbage collection of the ci_sessions table.

grails - how create new session for different browser tabs

I'm trying to create simple web-app using grails.
Now, I need create new session when user opens same page in different tabs to avoid displaying same data in all opened tabs.
is it possible to define that page was opened in new tab? if it possible how create new session in controller action?.
or maybe there is a way to get something like browser tab-id?
You seem to misunderstand how a session works and they are assigned.
A session is per browser (and domain/host).
So, even though you can create a new session in a controller action it won't help because that will become the session for all the tabs of the browser and the previous session(s) will be invalidated/abandoned.
There is no such thing as a browser tab id.
You'll need to address the root issue which is causing your data affinity to be based on a browser session. Make it based on something else. (Just a general suggestion since this isn't part of your questions and you haven't provided any details.)
Here is my thoughts on this.
What you are trying to accomplish may appear simple but you will need some mechanism to capture who each session be whether it be a spring security username or actual http session id and to then store with that what controller actions they have visited so far and to keep this consistently updated whilst checking it over and over again.
Something as simple as
[
['10001':[controller:'someController', 'someAction'],[controller:'someController1', 'someAction1'],
],
['10002':[controller:'someController', 'someAction'],[controller:'someController1', 'someAction1']
]
Where '10001' is your key of your map and is your session id then it contains a list of internal maps of places visited that you capture and try to work out if they been there already - basically the question here is....
Where is the AI to say if they have seen someAction1 they should see action2 and what happens when they seen action1 and action2 and so on an ever ending loop of and what next ?
Either way you could do all that as a session variable that contains a map like above - the issue you will hit will be concurrent map (where it gets updated and read at the same time).
So you will then need to look over and into using concurrent hashmaps to get around such issues.
Either way the problem with all of above is the consistent logic to figure out if they have seen all possible options then what next ?
I think you are far better off thinking of it from a different point of view as in base it on timestamp and move the query or whatever it is to randomly generate a different output based on that timestamp since that is always going to change regardless of the user

one session per user or one session in every users

I am curious about the value of PHPSESSID because, I created a simple login-type web app. When I try to login with different accounts, the value of the PHPSESSID is not changing. I got curious if it does okay or not. Because I tried to login in youtube with different account too. But their SID's differ on each user.
My question is:
1) Is what happening on my web app okay ?
2) Is yes, how can I make a session ids per account/user ?
3) If no, how can I fix it ?
I would really appreciate your suggestions.
It partly depends on exactly how you implemented "login." One way to do it is simply to change the user-identity (which, by definition, is part of the data that is stored in the session), while keeping the same session.
Another equally-valid way to do it is to first update the existing session (to show that the user, in that session, is now "logged off") (maybe...), and then to coin a completely new session-id, thus starting an entirely new session, in which you now "log on."
One advantage of the second approach ... and probably the reason why so many sites do it this way ... has to do with the possibility that the user might wish to open a new browser-window, and to log-in to the application a second time, intending to keep both logins alive at the same time. If the session-id token is part of the URL, or maybe is part of a hidden form or what-have-you, such that both session-id's can be retained independently, it becomes possible for the user to do what he has done without conflict. Two parallel sessions exist. In one, he is logged on as "joe," and in the second, he is logged on as "jeff." And so on. One set of browser-windows (somehow ...) carries the "jeff session" token; others carry the "joe session" token.
Fundamentally, a "session" is just a pool of server-side values, identified by the (PHPSESSID ...) token furnished each time by the client. Exactly how you choose to manage it, is at your discretion. It's a design-decision with no "correct" approach.

What is the reasoning for and the basic concepts behind an interstitial loading page?

I'm interested in finding out why this is used on some Web sites for processing user-initiated search submissions, how it affects the request and response flow, and programmatically why it would be necessary (or beneficial). In an MVC framework it seems difficult to execute since you are injecting another page into the middle of the flow.
EDIT:
Not advertising related. For instance, most travel sites used to do this, and there were no ads... some banking sites do it too, where there is just a loader that says something like "Please wait while we process your transaction...".
It is often used in long running requests to prevent the web server from timing out the request. With an interstitial page, you are able to continuously refresh the page until you get results back.
EDIT:
Also, for long running requests, it is beneficial to have a "Loading.." page in order to show the user that something is happening. Without the interstitial page, the request can appear to have hung up if it takes too long.
To supplement what HVS said, interstitials which appear before, say a homepage loads, are very much there for the purpose of advertising, we've all seen the 'close this ad' link.
One instance where they can be helpful from a user experience point of view is when a user initiates an action which requires feedback from a process which may take some time to respond - either because it's slow, busy or just has a lot of processing to do.
Think of a site where you book a flight online for example. You often get an interstitial on hitting 'find flights' because the the system is having to go off and ask for all relevant flight information and then sort them for you before displaying them on your screen. If this round-trip of 'request, interrogate, return, display' is likely to take an amount of time beyond that which a normal webpage transitions from one to the next, a UXDesigner may consider an interstitial screen (or message) to let the user know something is happening whilst at the same time allowing the system the time it needs to complete the request. Any screen with this sort of face-time is going to get the attention of your marketing department from a 'well while we've got them we might as well show them something' point of view.
As a UX Designer myself interstitials like this are not always preferred as I'd love every system to return data immediately but if it can't for whatever reason, I'm very much for keeping the user in the loop as much as possible about what is happening - rather than leaving them to stare at the browser status bar until they either try again or get fed up and leave.
One final point when considering this is also to have a lower and upper time limit on a screen like this. If you need to show an interstitial, show it for long enough so people can read it and understand it but not too long that they get fed up of waiting. As a rough guide, leave it open for at least 3-4 seconds (even if the process averages 4 seconds but has finished after 1 on this occasion). Between 4 and 10 seconds check every second to see if the process has responded (and then take the user to the next page f it has) and after 10 seconds seriously consider telling the user to either try again or telling them you've failed (whilst at the same time getting your tech team to fix what is ultimately a problem which will affect your bottom line).
I believe the vast majority of interstitial pages are there to run advertising.

Resources