Session scope not pertained

dev support
1

I’m having a weird issue, where I have a HTML/CSS/JS frontend website doing it’s thing, getting data from a CFML backend via an API-call.

It is this website https://ondernemerschap.panteia.nl/ and it gets its data from this API-endpoint: https://api.onderzoek.nl/ondernemerschap/.

Now this works peachy on the DEV-environment and for the most part on the LIVE environment as well, but for some reason the session scope at the CFML-backend is not pertained. NO matter what I do, the session-scope is never adding a session variable to the session-scope. Well, just long enough to set it and give it back to the user when he/she/they click on the “Download rapport” button. That send an API-call to a getToken function, that sets the token in the session scope and returns it in a JSON-data set. This is then used as a payload to the download-function that posts to the API-backend and there the posted token is checked towards the session-token. If they are the same, the download will commence.

On DEV this works peachy, on LIVE I only get the message that the token is not available in the session scope. I’ve set sessionManagement to true, set the clientCookies to true, sessionTimeout to half an hour, but it always returns the same error. What am i doing wrong?

Good to know, session management with exactly the same settings works on every other webapp on the same server, with the same code even. HELP!

Code from Application.cfc:

	this.sessionManagement = true;
	// this checks if a cookie is created, for bots this will return false and use the low session timeout
	this.sessionTimeout = createTimeSpan(0, 0, 0, 2);
	if (structKeyExists(cookie, "cfid") || structKeyExists(cookie, "jsessionid")) {
		this.sessionTimeout = createTimeSpan(0, 0, 30, 0);
	}

In all other webapps the cookie scope and the session scope trigger the wanted behaviour, how come the API-calls on LIVE do not, but on DEV do?

Don’t forget to tell us about your stack!

LIVE
OS: Windows 2019
Java Version: 11
Tomcat Version: 9.086
Lucee Version: 6.0.1.83

DEV
OS: Windows 2019
Java Version: 21
Tomcat Version: 11.06
Lucee Version: 6.2.1.122

2

Does it repo in dev with the same version as live?

I know you must have reasons, but it’s really a bad idea to not have dev match prod

3

Exactly the same version of code on LIVE as on DEV. It occurred to me when testing the code on LIVE after deploying it there. It’s just so baffling that the same code pertaining to sessions work in all the other webapps on the same server, but not in this one.

4

I meant the same Lucee version!

I did a lot of session related fixes with 6.2, you’re possibly hitting an edge case which I’ve fixed in 6.2 which is broken in 6.0

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

are the session cookies changing between requests?

5

It just remains for ever empty, it never fills up the cookie-scope / struct. Every request I dump the cookie scope and it just stays empty.

In other webapps on the same server nothing changes per request - the cookie scope is filled with what is expected and stays that way after that.

I’ve gone ahead and updated the Lucee version to the very latest: 6.2.1.122. Wondering if this will help the problem.

6

Nope, still the same problem :open_mouth:

Should I also maybe change this?

Loader Version 6.0.1.83

7

Shouldn’t but can’t hurt!

8

Nope, still the same issue :frowning: I’m baffled…

9

you’re seeing set-cookie and cookie headers being sent but they are not showing up in the cookie scope?

10

Right now I’m seeing all sorts of things flying back and forth, application-scoped variables being checked in one app belonging to another webapp, also on DEV. so I’m not really sure what’s going on with this version of Lucee??? Stress is rising enormously at the moment…

I’m in single mode as per the Admin’s, but it seems that once I start one webapp where a whole set of app-vars are set into the application scope and then start up another webapp, it tells me that a certain app-var that is available in the first but not in the second is not available in the second. Why??? It’s not even requested in that place in the code of the second app… This is really spooky. Everything is crumbling right now, and all the webapps were rock solid before the update to 6.2.1.122…

It might have something to do with the ORM-plugin. This has been removed from the 6.2.1.122 install and must be installed afterwards as an add-on for some reason?

11

On LIVE I’ve downgraded everything to 6.0.1.83, that was the latest stable version of Lucee. I’ll do that to the DEV environment too, because this is way too scary what we’re witnessing here…

It is as if only one webapplication at the time can be active and all other webapps being started are inheriting settings from the first webapp started on the server. And all error out in the same way. Application scoped variables not being found, FW/1 pages not available, as if the variables scope is omnipresent but only decided by the first webapp run on the server. This is really shitty - unfortunately there are no Windows installers for 6.0.1.83, so I’ll try my luck with installing 6.0.3.1 and see how that fares…

12

There’s only one application namespace in single mode, so if you’re using “CRM” on host1 and CRM on “host2” that the same application scope?

13

Every webapp has a config struct where all the settings for each specific webapp is stored. If the single mode bunches it all together and doesn’t create a unique struct for each webapp, then it is logical that the config-struct created by the first webapp is used for all webapps. But that is just crazy! Why would anyone want to use single mode then??? Each application has it’s own unique name, so I assume all settings and variables and structs should pertain to only that one webapp, not share it across all webapps if in single mode?

14

OK, switching from Single Mode to Multi-mode saved my vacation, pfffff…

We’ll not be moving to Lucee 7 if this is the result. How are we supposed to maintain integrity in Single Mode? I do not understand how this will work. We’ll have to rework everything for the 30+ webapps on the one single server… And no, we’ve not Dockerised, as this increases the management burden. Lucee 6 works hard, but is never stressed out serving these 30 webapps.

I’ve upgraded back to 6.2.1.122 and also the loader JAR is that version and everything seems to be back to normal now on DEV!

Brings me back to why the session-var does not work in the LIVE-environment, the original reason for this issue :wink: . But for now, I will try and work around that on the LIVE-environment and continue to be baffled…

15

You could be hitting this bug which was solved in 6.2.2.10

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

I’d suggest trying the latest 6.2.2 RC which includes this fix.

16

Does this fix that variables.config struct in one webapp will be treated differently from variables.config struct in other app. I.e. see them as separate and unique structs belong to their own webapp? The same with application-scoped variables with the same name?

17

Do you mean this.name="app" on host1 and this.name="app" on host2, or application.dev=1 across different application names?

without seeing what your code, I can’t answer those questions, but it definitely solves one of the single mode issues, variables.config ain’t enough info

18

OK, we’ll see when the 6.2.2.x version comes out.

For now we have a FW/1 webapp where we set lots of variables into the Application scope included in a CFM-file in the Application.cfc. That struct is then used all over the webapp. This is the struct that was causing issues yesterday in Single Mode, where all the app vars where bleeding over into other apps, whilest the same way of setting of app vars was not being honored in the webapp itself. So I guess the application-scoped vars of one webapp were available in the others, but their own application-scoped vars were not seen. The error was also shown to be a place that was not correct, sayng that appvar01 is not available in the struct on line 35 of file x.cfm. But there a variable was set in the middle of a struct, so the error referenced a bogus place.

App.cfc:
======
	public void function setupApplication() output=false hint="" {
		// clear all caching (pages and CFC's) if needed / dirty
		inspectTemplates();
		application.development = this.development;
		...
		// include application variables (global and local)
		include "config/applicationVariables.cfm";
	}

config/applicationVariables.cfm:
==========================
	variables.appStruct = {
		adminSkin : "purple"
		, ageStart : 1
		, ageEnd : 99
		...
		, studylevel : "A/B/C"
	};
	StructAppend(application, variables.appStruct);

App.cfc:
======
	factory configuration function:
	========================
	// add config bean to factory
	bf.addBean("config", new config.global().getConfiguration());
	var config = bf.getBean("config");

	public void function setupView() output=false hint="" {
		var bf = getBeanFactory();
		var config = bf.getBean("config");
		/* i18n, Locale handling */
		var strLocale = structKeyExists(session, "locale") ? session.locale : config.defaultLocale;
		setLocale(strLocale);
		...
		rc.cspHeaderConnect = application.cspHeaderConnect;
	};

Then in another webapp it would say that the application variable ageStart or rc-scope variable cspHeaderConnect did not exist, when starting up the other webapp (assuming the webapp where the above code is an example of was started first on the server).

The reference to the error would then be in a struct called config being set in config/global.cfc referenced from the setupView() function showed here above.

public struct function getConfiguration() output=false hint="" {
	/* get Database config settings */
	var settingsService = new path.to.service.in.model.settingsService();
	var settingsObj = settingsService.getObjBy({ serviceVar : cgi.server_name });
	var config = {
		allowSpecialCharacters : ["backslash", "forwardslash"]
		...
		, version : settingsObj.getVersion()
	};
}

F.ex on this line:

29:   , defaultLocale : settingsObj.getDefaultLocale()

Really has nothing to do with the error being reported: “the variable ageStart is not available in struct”.

Very confusing all in all and not really able to make heads or tails of it. I thought maybe it had something to do with the variables scope pertaining over from one webapp to another, or something with ORM when we set a property for a service in a CFC and reference it via the variables-scope (i.e. property reportService => variables.reportService.getStuff()).

Anyways, once we returned to the Multi Mode all was back to normal :slight_smile: .

19

yeah the dotted instance syntax for the settings service is probably hitting that exact issue

https://luceeserver.atlassian.net/browse/LDEV-5536?focusedCommentId=60485

1 Like
20

I have an idea which I wish to suggest for you to test. If I remember correctly, Single-Mode means that all the web applications (webapp1, webapp2, etc.) are served from a single servlet context. They therefore share the same Lucee engine instance.

So I wondered: do the issues you describe arise because you are using the same value for this.name=“appName” in the Application.cfc of each web application? If so, what happens when you use a unique name for each web application?