Different browsers may have a different approach. What is important:
a) Is the access a non-localhost/non-loopback address (that includes any loopback IP IPv4 and IPv6 )?
b) If a) is true, does the connection has a secure valid connection (valid HTTPs)
@webguyks on the image part 2 you can clearly see the yellow exclamation mark “!” on the right side of the session cookies in your dev tool panel. Do a mouseover on that and you’ll see the cause in verbose text.
Part 3 is a loopback address with 127.x.x.x, thus the secure flag is ignored.
I just installed Lucee 5.4.3.2 on fresh Windows server and see this same behavior. Every click takes me back to login screen. I can also confirm using Chrome browser dev tools that the cookies are indeed marked as “secure only” and therefore being blocked.
I am accessing Lucee admin via Tomcat port 8888. This is a vanilla install.
For me even accessing via local address 127.0.0.1:8888 is blocking.
a) My address is a loopback address. The url is resolved to 127.127.1.166 in my example above.
b) All of my connections in my local environment are not secure. They are all going over http and not https.
Doing the mouseover results in the same message you have in the image you posted to this thread.
Thank you for confirming my suspicions on the loopback address.
The local address (port 8888) for me is not causing the condition of constantly being logged out. It is only when I attempt to use http://testlucee.loca/lucee/admin/server.cfm. It is an HTTP and not an HTTPS connection.
However…this did not occur until after I had installed the URL Rewrite 2.0 module for IIS.
Initially, before installing this module, I was able to access the lucee admin from http://testlucee.local/lucee/admin/server.cfm and could navigate to each page after logging in successfully without being logged out.
@webguyks what you commented underlines all my findings. Lloopback IP addresses are just treated as secure by chrome,.even on “http”, while a http request to a custom domain is NOT treated as secure and will need a https:// request.
I’m experiencing the same issue on multiple servers. This issue emerged AFTER we updated all of our instances after the CVE security alert a few weeks ago. No issues prior to the updates.
On one of our DEV servers with multiple contexts, only the older contexts have the issue, while two newer contexts do not. Same browser, same settings, yet different results.
DEV Stack:
OS: Windows Server 2019 (10.0) 64bit
Java Version: Apache Tomcat/
Tomcat Version: 11.0.11 (AdoptOpenJDK) 64bit
Lucee Version: Lucee 5.3.12.1
IIS 10 with URL Rewrite 2.1
I’ve tried using FireFox, WaterFox and good old IE11 with the same result.
I’m experiencing the same issue on one of our production servers:
Production Stack:
OS: Windows Server 2019 (10.0) 64bit
Java Version: 11.0.11 (AdoptOpenJDK) 64bit
Tomcat Version: 9.0.35
Lucee Version: Lucee 5.3.12.1
IIS 10 with URL Rewrite 2.1
This afternoon I spun up a fresh AWS EC2 instance running:
OS: Windows Server 2019 (10.0) 64bit
Java Version: 11.0.20 (Eclipse Adoptium) 64bit
Tomcat Version: 9.0.78
Lucee Version: Lucee 5.3.12.1
IIS 10 with URL Rewrite 2.1
with the same result.
In all cases the Lucee Admin is running on a local IP address on port 80, and the Lucee Server Admin is bound to 127.0.0.1 This issue has not affected the Lucee Server Admin.
The cookie rejection may not be a factor. I’m receiving similar cookie errors in the FireFox browser console and no errors in the IE11 console in cases where I’m not being repeatedly asked for the password.
@Alexander_Archaro Are you saying in Firefox it works, also after it clearly saying the cookies are being rejected (see your screenshot)? This really can’t be!
Also, you are not using a loopback address. Local IP 172.x isn’t a loopback address and may not be interpreted as secure. IE11 is out of support.
Basically it 's easy to verify: Just see if your browser is sending the cookie or not through the dev tools network tab (request headers).
@Miguel-F really welcome Miguel! Nice to see a prominent cfml StackOverflow user here in the Lucee Community! Thanks for joining and confirming the issue.
Thank you @andreas . It is good to finally be here. I have tried for years to switch from Adobe CF to Lucee. Finally the company I work for has agreed to try it out. So while I have worked with Adobe CF for a long time, this is my first time using Lucee.
Glad to see the community here seems to be very supportive. Cheers!
What is the “fix” in this snapshot version? Are you taking away the secure cookie by default? Am wondering because I’m building a production server and don’t want to use a snapshot version for that.
I am new to Lucee and was just surprised by this issue. I read nothing about it in the installation docs. I understand the need for the secure cookies and would be happy to just add TLS option for Tomcat to serve the Lucee admin over secure connection. Just cannot find that anywhere in the Lucee documentation. I know it has been documented for Tomcat and will likely proceed with those steps.
As per our normal development process, we produce snapshots which get tested, then we are planning on making a release once we have confirmation that the issue is resolved for those affected.
the fix was to check the cgi and proxy header variables to determine if the request is secure and then only set the secure flag when appropriate, I collaborated with @bdw429s on the solution, we are using some battle tested code from Ortus. Even if due to your config the flag doesn’t get set, the admin cookies are scoped to the admin folder path and have httponly also set.
I just downloaded 5.4.3.9-SNAPSHOT.lco and can confirm that it fixed the admin cookie issue. The cookies are no longer marked as “secure only” since I am not using https.
Thanks for the quick work in getting that fixed for us!
All good! Yesterday I provided some information directly to @Zackster when I found that issue, and he was pretty fast getting that bug fixed (I think he got some quick additional help), so I was able to test that new build pretty fast to get the new snapshot released ASAP. And that makes me really happy! Lucee
between all this positive feedback on these issues and the great feedback about the [LDEV-3854] - Lucee pagePool locking, we are pretty much good to go on releasing a stable 5.4.4
Lucee