URLSessionFormat() function does not work when using JEE/J2EE sessions when a client does not accept cookies
Description
Environment
OS: Debian 9.13 - Linux
Java Version: openJDK-11.0.11
Tomcat Version: 9.0.48
Lucee Version: Lucee 5.3.8.201
Attachments
- 26 Sept 2021, 01:19 pm
Activity
Knut Bewersdorff 17 October 2023 at 11:13
@Michael Offner
So
setClientCookie=falsealways forces the parameter to be addded, what is the correct behaviour in my opinion.
I'm sorry, but I don't understand the logic. Why does setClientCookie=true have to be set, so that the jsessionid parameter is not always appended? - When I use JEE sessions, I don't want to use the client cookies (CFID and CFTOKEN) and therefore I use setClientCookie=false and clientManagement=false in the Application.cfc.
so if
- the variables setClientCookies was set to false in the application.cfc
- if there are no cookies send by the client
just one of this condition need to be true.
If you use the URLSessionFormat() function, it is normal that a JSESSIONID cookie is not recognized on the very FIRST REQUEST. As a result, the jsessionid should be appended as a parameter for the next request. Lucee (or ACF) SET it, to be delivered in the FIRST RESPONSE. From my point of view, it shouldn't matter whether setClientCookies=false or setClientCookies=true for all following requests.
The problem was discussed with Charly Arehart at https://dev.lucee.org/t/how-to-reliably-check-if-the-jsessionid-cookie-was-set-in-the-client-browser/9931/2 and Charly wrote:
But note first that you will NOT be able to detect cookie support on the very FIRST page request someone ever makes to your site, at least not from the server code alone. The problem is that when someone visits your site for the very first time, there will BE no session cookie (jsessionid, in your case). So Lucee (or ACF) would SET it, to be delivered in the first RESPONSE.
Maybe it's just a question of the order in the decision logic?
If you first check if there are no cookies send by the client and then whether the variables setClientCookies was set to false in the application.cfc
If you use JEE Sessions, adding the jsessionid as a parameter via the URLSessionFormat() function from the second request onwards should, in my opinion, depend solely on whether a JSESSIONID cookie exists or not. I hope I haven't made any mistakes in my thinking.
Michael Offner 13 October 2023 at 07:42
@Knut Bewersdorff if so, lucee will always add the parameter, independent of if the client send cookies or not.
Knut Bewersdorff 12 October 2023 at 08:57
@Michael Offner I'll be traveling on business until Sunday evening and won't be able to check this in more detail until next Monday. But I'm very sure that I set "setClientCookie=false" in the Application.cfc. I have to check it out on Monday.
Michael Offner 12 October 2023 at 07:45
@Knut Bewersdorff @Pothys - MitrahSoft the current version looks like this
it only attaches the url parameter if one of the following 2 conditions are true:
if (!pc.getApplicationContext().isSetClientCookies() || ArrayUtil.isEmpty(cookies)) {so if
the variables
setClientCookieswas set tofalsein the application.cfcif there are no cookies send by the client
just one of this condition need to be true. that means when you have set setClientCookies to false it will still add the parameter even the browser does send the cookies. because that variable can be set different for every request and only count for the current request. So setClientCookie=false always forces the parameter to be addded, what is the correct behaviour in my opinion.
Do you have that variable set or not, if not the question is why do you still see the parameter be added, do you really get back cookies from the client?
You can find out by adding the following to your test code
https://trycf.com/gist/4384832be3cd9763aaebcb4851196941/lucee5?theme=monokai
Pothys - MitrahSoft 11 October 2023 at 09:39(edited)
@Michael Offner I checked this ticket with lucee version 5.4.4.15-SNAPSHOT. The "jsessionid" is now always added whether the client browser accepts cookies or not. But the acf only added a jsessionid when the client browse not accepts the cookies.
Details
Details
Assignee
Reporter
Priority
BlockerNew Issue warning screen
Before you create a new Issue, please post to the mailing list first https://dev.lucee.org
Once the issue has been verified, one of the Lucee team will ask you to file an issue
The URLSessionFormat() function does not work when using JEE/J2EE sessions and ALL cookies are disabled in the client browser.
The forum user "cfmitrah" confirmed this as bug. He wrote:
You are right. Disable cookies in the browser and running test file throws error key [COUNTRY] doesn’t exist. ACF works fine. Could you please file a bug in Jira? Link to the forum post
Error reason:
Lucee appends the ‘jsessionid’ in a way that does not comply with the Java Servlet Specification 4.0 because Lucee adds the jsessiond as a query variable and not as path to the URL. The specification describes the following:
7.1.3 URL Rewriting
URL rewriting is the lowest common denominator of session tracking. When a client will not accept a cookie, URL rewriting may be used by the server as the basis for session tracking. *URL rewriting involves adding data, a session ID, to the URL path that is interpreted by the container to associate the request with a session.
The session ID must be encoded as a path parameter in the URL string. The name of the parameter must be jsessionid.* Here is an example of a URL containing encoded path information:
http://www.example.com/catalog/index.html;jsessionid=1234_
All additional URL parameters must then be appended as query parameters after the jsessionid in the following form: ?varA=1&varB=2
Complete example: http://www.example.com/catalog/index.html;jsessionid=1234?varA=1&varB=2
I'*ve added a test scenario to demonstrate the bug. It also includes a small "workaround" just for temporary use (in case anyone needs it).
Only the "jsessionid" should be added to the URL path when using "J2EE/JEE" sessions. Adding the CFID and CFTOKEN only makes sense when using "CFML" sessions. It would be great if this could be taken into account when the bug is fixed.
Thank you.