Maintaining sessions across IPs

I’ve developed an application for our Project Managers, which uses SessionManagement currently set to a datasource. The Project Managers are all on laptops, and are constantly moving from docked (wired) to undocked (wifi). WiFi is currently configured on the same subnet as wired, but the IP will change in the transition from one to the other.

The PM’s sessions appear to expire during this transition, even though SessionTimeOut is set to 2 hours (internal intranet).

Is there a configuration of session storage/cookies/tokens that will help keep these sessions open?

TIA,
-Carl

I would ignore session storage for a bit and simply answer the question of whether or not they are getting a new jsessionID or CFID. If so, that means they’re getting a new session.

Also, do you have more than one server in play? Is there a load balancer in the mix? What is your sessionCluster setting set to?

No, no cluster at all. Single server.

I’ll see if I can’t monitor the CFID better for troubleshooting (sessiontype is currently Application, rather than j2ee)

Just open up the Chrome debugger and look at the cookies in your browser. Next, change your internet and refresh the page. Look at the cookie values to see if they changed. If so, confirm that the browser’s HTTP request headers still sent the old cookie. I’m not aware of any Lucee setting that cares about the IP of the user. So long as the HTTP request comes in with a valid CFID cookie, the session should get picked up.

So I’m doing my own authentication, storing user data to the SESSION in a struct
SESSION.loggedinuser.[key]

Near as I can tell, during the transition from the networks, the SESSION id remains the same but the SESSION.loggedinuser struct is gone.

What exact version of Lucee? It shouldn’t make a difference, but that may come into play.

Run a test. Wipe your DB table and hit the site which should insert one new record in the table to represent the session. Usually the key includes the app name and session id, etc. Next change your IP and now check if a second record has been inserted into the DB table. If so, what is different about the primary key?

I’ve had a similar issue for a long time.

I found putting sessionRotate(); at the end of a request where the user logs in fixes the issue.