http://coldfusion.com logo
Join Slack
Powered by
<@U070SQMD1> we have a regression at snapshot 140....
# lucee
s
@zackster we have a regression at snapshot 140. It is either the session management or cookies, we are currently trying to narrow it down. The bug is, a user needs to log in each time they browse to a new page. - more details to come as we get them. However, was there anything changed between .139 and .140 that may cause either session or cookie management issues ? It may help us narrow down the issue.
b
@steveduke There was a fix related to how cookies are read in this release
It's tagged as patch 140
What servlet are you running Lucee on and do all your cookies show up in the cookie scope?
s
Thanks for the update. we are running Apache Tomcat/8.5.77 Java 11.0.15 (Eclipse Adoptium) 64bit
I'm checking on the cookie scope now ...
b
@steveduke What did you find?
s
Sorry to leave you hanging there Brad. This is part of the authentication code. I'm going to need to wait until that dev is available to test further, which most likely will be Monday. Meanwhile (this weekend) I'll see if I can replicate what I'm seeing in a simpler environment to test and share.
👍 1
z
@steveduke any luck?
s
I have booked some precious time with the dev responsible for the code in question this afternoon. I'll get back to you with any results we find.
hi, we found that lucee no longer reads cookies set to SameSite=None from version .140
b
Ahh, can you come up with a quick repro case where you set a cookie that isn't read? That should make it easier to get tracked down and fixed. @steveduke
s
We're working on that repo case. It appears to respond differently in our test environment, so it's going to take a bit more time to recreate. But, we'll work on it.
b
@steveduke Are you also setting the 
Secure
attribute in the cookie?
I noticed the spec requires that when 
samesite
is equal to 
None
, the cookie's `secure" attribute must also be set or the cookie will be blocked.
Can you just share the code where you set the cookie?
And when you say it's "no longer reading", do you mean to say the cookie does not appear any longer in the 
cookie
scope?
@steveduke In my quick test, a cookie with 
samesite
set to 
None
is showing up in the cookie scope
message has been deleted
s
This is the issue we see from our prod environment (we are so far unable to replicate in a test environment) : setting the cookie -
Copy code
<cfheader name="Set-Cookie" value="testMyCookie=abcd1234;Path=/;Domain=.mysite.com;SECURE;HttpOnly;SameSite=None;Expires=#dateTimeFormat(dateAdd('d',90,now()),"ddd, dd-mmm-yyyy HH:nn:ss","UTC")# UTC"/>
Running the code from an older version of Lucee (5.3.9.139) we see the SameSite=None set in the cookie:
Copy code
testMyCookie=abcd1234;Domain=.<http://mysite.com;SECURE;HttpOnly;SameSite=None;Expires=Mon|mysite.com;SECURE;HttpOnly;SameSite=None;Expires=Mon>, 22-Aug-2022 17:38:05 UTC;
running the same code on 5.3.9.140 we see :
Copy code
testMyCookie=abcd1234;Path=/;Domain=.<http://models.com;Expires=Mon|models.com;Expires=Mon>, 22-Aug-2022 17:35:33 UTC;Secure;HttpOnly
The auth dev has an idea why, and will pick this up again tomorrow.
b
@steveduke When you say "we see" where are you looking? The browser debugging? The HTTP request headers?
I'm unclear if the issue is happening when • the cookie is sent from the server to the browser • or when the browser sends the cookie back from the browser to the server
I'd check for any web servers or proxies in the mix that may be modifying HTTP request or response headers too.
s
we are looking from the browser
b
That doesn't really answer my question, lol
If my wife asks if i'm looking in the fridge or the sink for a spatula and I tel her I'm looking "in the kitchen", that doesn't really answer 🙂
both the debugger tab's cookie list and the request headers are "in the browser" but they are two different places
s
lol, sorry. Quick trigger finger on the return tab!
b
For example, my screenshot above was the debugger's "cookies" portion of the 'application" tab (in chrome)
But there's also the "request headers" section of a selected request in the "network" tab (in chrome)
Also, this may seem obvious, but are you actually testing over an HTTPS connection on dev?
s
In the request headers I see the cookie being requested from the browser In the response headers I see no set-cookie for this cookie
b
I was just testing locally in Chrome and even tough I set the cookie, Chrome gave me a warning that the cookie would be ignored because my connection wasn't secure
s
Yes, everything is https
b
In the response headers I see no set-cookie for this cookie
This will only happen on the specific page that sets the cookie. Can you confirm because I defo see a set cookie in my HTTP response when I test that same cfheader code
In the request headers I see the cookie being requested from the browser
I don't quite follow this. Cookies aren't "requested from" the browser. The browser just sends them to the server in the HTTP request headers.
s
OK, that's want I meant. In the browser request headers.
b
Ok, cool. So... where exactly is the problem then, lol. What seems wrong/missing/etc?
Here's what I'm seeing. I started a local CommandBox server running Lucee 5.3.9.141 using SSL. I put this code in the index.cfm file
Copy code
<cfheader name="Set-Cookie" value="testMyCookie=abcd1234;Path=/;Domain=.fakedomain.com;SECURE;HttpOnly;SameSite=None;Expires=#dateTimeFormat(dateAdd('d',90,now()),"ddd, dd-mmm-yyyy HH:nn:ss","UTC")# UTC"/>
When I visit the page, I see this response header
Copy code
set-cookie: testMyCookie=abcd1234;Path=/;Domain=.<http://fakedomain.com;SECURE;HttpOnly;SameSite=None;Expires=Mon|fakedomain.com;SECURE;HttpOnly;SameSite=None;Expires=Mon>, 22-Aug-2022 22:21:58 UTC
leading to this cookie showing in the application tab
s
I know! It's quite frustrating. We're attempting to pin it down. The failing set-cookie is deep in the Authentication code. Trying that set-cookie on its own, outside of its current code and I'm not seeing the problem, which indicates a code error, however, I only see the issue on lucee version .140+ . And this section of code has been running since iPods were a thing.
b
Refreshing the page sends this response header
Copy code
cookie: testMyCookie=abcd1234
and the Luce 
cookie
scope contains the value
message has been deleted
Does the cookie value have a space in it?
Also, I'm still unclear on my previous question, which is what exactly is the issue.
s
no spaces in the cookie
👍 1
b
is the issue that the 
Cookie
header is sent from the browser to the server but the cookie itself is missing from the CF 
cookie
scope?
or is the issue simply that the 
set-cookie
header coming from the server to the browser is missing information?
@steveduke
s
That's what we were attempting to clarify today. Running this in the test environment to check, but we cant get it to error there. There are 2 domains: sub1.d.com and sub2.d.com the cookie is set for .d.com when the cookie is set in sub1.d.com, and then we browser to sub2.d.com, and cookie is not returned in set-cookie. if the cookie is set in sub2.d.com, and then we browser to sub2.d.com, and cookie is returned set-cookie works fine.
the cf cookie scope for the production authentication system I have not checked. I'd want to check that in a test environment.
b
Don't bother with the cookie scope if it's not set correctly in the browser in the first place
That's really the very first question to answer
How is the cookie getting set in the browser and is the set-cookie coming back correctly from the server
s
Yep. that's our goal. Frustrating we cant replicate it yet. The Dev is back on this tomorrow, so we'll have grasp of what's happening then.
b
It appeared you were pasting part of the 
set-cookie
HTTP reponse headers above, but I'm a little confused because later you said "_In the response headers I see no set-cookie for this cookie_" so I'm not clear what's happening.
I would recommend getting the dev here on Slack
This doesn't feel like it should be that hard to debug,. but we have to be able to tell what is actually happening, lol
s
I know! lol.
b
When debugging cookies, you need to work your way in order or you're get hung up on irrelevant downstream details
So, check in this order • is the correct set-cookie response header coming back from the server to the browser • is the cookie stored correctly in the browser • is the correct cookie request header being sent back to the server • is the cookie showing up in the cookie scope
because if the issue is in bullet #1, you can just skip all the other stuff and focus there
it's also worth noting the change in Lucee build 140 really only applies to bullet #4 unless something else changed I'm not aware of
I also just tested hitting my local test site on two separate subdomains and the browser is sending the cookie every time.
s
as I said, frustrating, lol.
b
The 
domain
of my test is 
.<http://fakedomain.com|fakedomain.com>
and the browser sends the cookie to the server for both 
<http://foo.fakedomain.com|foo.fakedomain.com>
and 
<http://bar.fakedomain.com|bar.fakedomain.com>
Don't get frustrated, get organized 🙂 Test one thing at a time using my bullets
And get your CF dev on here.
He should be here anyway 😆
s
He's the authentication dev.
b
Not sure what that means, but he still needs to be in here if he wants to be able to help debug without proxying through you like a game of telephone
s
It means, its his code base
b
Great, get 'em in here!
s
"The 
domain
of my test is 
.<http://fakedomain.com|fakedomain.com>
and the browser sends the cookie to the server for both 
<http://foo.fakedomain.com|foo.fakedomain.com>
and 
<http://bar.fakedomain.com|bar.fakedomain.com>
" For us that second domain would be running on Lucee build 5.3.9.133
b
I'm confused then-- your first post in this entire thread was that the bug was in build 140+, but now you're saying the issue is only happening when you hit build 133?
s
we would set the cookie for the second domain and not see he correct set-cookie response header coming back from the server to the browser
b
we would set the cookie for the second domain
This is also confusing as your example above set a "domain" cookie, which applies to all subdomains.
Copy code
Domain=.<http://mysite.com|mysite.com>;
which is it?
and not see he correct set-cookie response header coming back from the server to the browser
Explain-- no header at all, or a different header than you expect? And in what way was it incorrect?
And let's go back to this, because after re-reading it, it also doesn't make sense
when the cookie is set in sub1.d.com, and then we browser to sub2.d.com, and cookie is not returned in set-cookie.
If the cookie is set in code running in the sub1 server, then ONLY the HTTP response from the sub1 server would contain the 
set-cookie
. No requests to sub2 would include a 
set-cookie
header in their response unless they also ran CFML code to set a cookie. If you're only running the cfheader code on sub1, then you should not expect to see any sort of 
set-cookie
response header from sub2.
s
okay, • I think we need to get a working test environment to help us. • and get the dev for this code in this chat - lol • setting the cookie in either sub domain has the same issue. Which is after setting the cookie in one of the sub domains, there is no set-cookie in the other sub domain response headers • we only see this behavior in our production environment for the authentication code
But we really need to dig deeper to get a better grasp on whats happening
b
there is no set-cookie in the other sub domain response headers
Why would you expect to see one? That's not how cookies work
Again, a set-cookie response header is a one-time thing that only happens on the specific page that sets the cookie. After that the browser stores the cookie and returns it in a 
cookie
request header on every request.
So to review • You'll only see a 
set-cookie
HTTP response header come back from the server when you've explicitly set a new cookie on that request. • you'll see a 
cookie
HTTP request header on every subsequent request containing all cookies the browser has for that domain.
@steveduke
s
"HTTP response header come back from the server when you've explicitly set a new cookie on that request" It's part of the authentication and user management system, so it's most likely being set on every request. However, • I think we need to get a working test environment to help us. • and get the dev for this code in this chat - lol
👍 1
I do appreciate your help
b
so it's most likely being set on every request.
I wouldn't think so. I mean, it's possible, but that would be a very curious and odd design.
The point of cookies is you set them once and the browser remembers them
So it would seem rather unnecessary to be continually re-setting the same cookie that was already set.
s
We have implemented a working solution. This is what we found. The cookie value in the header was not url encoded and the cookie in question had the "=" character in its value. The cookie scope value was truncated up to but not including that "=" character. Our working solution is to use cfcookie instead which supports samesite. (url encoding the cookie value would also work). Weird thing is, how it ever worked in the first place.
z
we did some work on cookie encoding quirks in 5.3.9
i have this test case which wasn't merged in yet (hmmmmf) https://github.com/lucee/Lucee/pull/1603/files
just rebased it and running the test suite now
two of em are failing, one with serialize and one with a missing ; [java] [script] Failed: testCookieEncodeExtended --> Expected [{"test_tag1":"somevar","RULES":[]}] but received [%7B%22test_tag1%22%3A%22somevar%22%2C%22RULES%22%3A%5B%5D%7D] [java] [script] at [java] [script] /home/runner/work/Lucee/Lucee/test/tags/cookie.cfc:33 [java] [script] [java] [script] Failed: testCookieEncode --> Expected [space& & space & &nbsp;] but received [space& & space & &nbsp] [java] [script] at [java] [script] /home/runner/work/Lucee/Lucee/test/tags/cookie.cfc:18
b
@steveduke Ahh, so you remember way back when I asked you what the actual value of your cookie was and whether it had a space in it? This is why I asked and if you had told me the actual value back then we could have saved about 2 days of back and forth. There's a reason I tried to eliminate an invalid cookie value as the issue 😉
So basically, the answer is this • You weren't using the cookie scope or the cfcookie tag to set your cookie and opted to manually build the HTTP header, which meant the onus was on you to follow the proper HTTP specs • Your cookie header did not follow the proper HTTP specs as the RFCs for cookies disallow certain characters in the value • Lucee has some undocumented code in place that will "bend" the spec for you in order to try and allow invalid cookies to actually work • That code in question is what changed in the snapshot where you saw the behavior change
s
While I do appreciate help, the tone is a little suspect. It also makes me not want to participate in these discussions with the Lucee community.
b
I'm sorry if I came across that way, but I also get frustrated when I try and try and try to get information about of people to help, only to find out days after, one of the first questions I asked would have helped solve the issue. It's not just you, this happens to me all the time.
Don't take it personally-- I'm trying to help you ask for better help next time
I was familiar with the code that changed in that build and knew it dealt with allowing non-compliant cookie values, which is why I asked early on about the value of the actual cookie.
s
I get it, and I really do appreciate the help. In this instance, I had no means to recreate the failing environment until yesterday. So I couldn't provide you with answers to your questions. Yesterday we were able to break out the code and run tests to finally work out what was breaking.
b
Yep, that happens. Were you at least able to get your CF guy on here? Next time you can make him ask the questions 🙂
s
The author of that code. No. We didn't need to once we were able to break out the code and run tests.
That was the most frustrating part is testing outside the black box environment
👍 1
b
Got it-- well, I'm glad it's working for you. Your scenario was certainly not anything that would have been obvious. Especially since Lucee has not documented in what way they allow cookies to bend the spec. It's just something they... do.
s
Your biggest help was explaining how the Lucee team had changed the way they read the cookie.
That was the penny drop moment once we started testing
4 Views
Open in Slack
PreviousNext
Powered by