Hey gang,
Weird issue I have never encountered before.
When using either server or web admins,…
I can initially login fine - but as soon as I click on any item - I am kicked out and prompted to login, again.
Don’t forget to tell us about your stack!
OS: “Ubuntu 18.04.6 LTS”
Java Version: 11.0.18+10
Tomcat Version: 8.xxxx
Lucee Version: 5.3.10.97
Many an odd Lucee admin issue can be fixed by clearing your cookies.
Hi Brad,
Thanks - I forgot to mention that I did that.
I even tried to use incognito mode, too - to no avail.
Then maybe it’s the other way around. Is your browser configured not to accept cookies?
Is this happening in a single browser, or in more than one? Does the server have any sort of special settings for session storage in place?
Have you tried another browser, e.g. firefox if you usually use chrome, just to rule out that its an server or browser issue? I had a very similar issue once with chrome, tried then on firefox and everything was fine. I had to delete cookies, emtpy the complete browsers cache and even the browsers history… That only resolved the issue.
Thanks @andreas - I’ll give it a try.
I’ve the same issue.
Here are the steps I took that got me to the point of issue:
I did not create any rewrite rules.
I tried uninstalling the rewrite module and restarted Windows.
The issue persists. I can no longer utilize the server admin using the website address. I can utilize it from the IP address with the correct port.
Can any shed light on this?
Could you try the latest snapshot 5.4.3.8 to check if the issue persists there? Please make sure to remove all cookies of your browser when you access the admin.
Thank you for the quick reply!
I’ve tried it out. No luck.
After login now, it is displaying the login form at the top of the page. I’ve attached an image. It still logs me out as well after clicking any of the links.
My environment:
Windows 10.0.19045 Build 19045
Chrome 116.0.5845.180 (cleared cache before trial)
CommandBox 5.9.1+00767
server.json:
{
"app":{
"cfengine":"lucee@5.4.3-SNAPSHOT+8"
},
"name":"proofTest",
"profile":"development",
"web":{
"host":"proofTest.local",
"http":{
"port":"80"
},
"rewrites":{
"enable":"true"
}
},
"webroot":"c:/proofTest/"
}
so let’s take a step back and look at this problem, we are after all web developers right?
what’s going here is the cookies aren’t sticking, that’s why the request after login works and the next request is prompting a login.
so how do we debug this problem? now that i have set out the problem, let’s diagnose
firstly as other have suggested, try in incognito/private mode, that means each round of testing, close and reopen the private/incognito browser window.
look at the response in dev tools from the login, there will be a set-cookie header
5.4.3 sets path scoped cookies for the admin, i.e path=/lucee/admin (latest version 5.4.3.8 also works for rewritten / remapped admin paths like /blah/lucee/admin)
the next request should then be passing the cookies from the set-cookie header to the next request, if they aren’t passed, that’s the problem
also check the browser console for cookie warnings and the dev tools panel to see what cookies are set
try this is both FF and Chrome
do all this with the latest 5.4.3.8-SNAPSHOT, that should always be one of the first steps in debugging a problem with Lucee, try the latest SNAPSHOT as you might be simply battling already solved tech debt
Just a thought, since ran into a similar issue when deploying my application to a production server. On the production server running Tomcat (please don’t chastise me!) I am trying to redirect 80 to 443, which I haven’t been able to get working yet. Anyhow, I was accessing the admin URLs with plain HTTP and getting prompted for the password with every request. Once I switched to HTTPS, everything started working.
Ross.
@Zackster remember that I had a similar issue with 5.4.3.2 as we did the update tests? However, I’ve not experienced nothing similar with 5.4.3.8 Snapshot. If somebody encounters this issue with 5.4.3.8 please report how to reproduce it with details. I wasn’t able to reproduce it.
I think I may have found the problem. The session cookies are marked as secured, but you may be accessing over a non-secure connection (port 8888) and not a “localhost” (on localhost the browser seem to ignore the secure=true cookie flag). Thus, Chrome (or other browser) are not resending the cookies and forcing a repeated logins on non-secured and non-localhost URLs!
If anybody (@webguyks @Ross_Naheedy ) seeing this issue: can you please confirm if these are the same circumstances happening in your admin requests during repeated login?
Part 3:
I had to break up in 3 parts to get the images (which are worth a 1000 words)
In Chrome, but with the IP instead of the domain url:
Does not log me out and functions like it does in FireFox with the domain url above.
I verified that the cookies are indeed getting set as secure, even when the connection is just HTTP. That’s why accessing the pages via HTTPS works. Lucee installation is 5.4.3.2 and I tested under Firefox and Brave in Linux, but last night Brave under Windows was doing the same thing.
Ross.
In my testing above, none of my urls are unsecure. Yet, I get different results in the two different browsers and a different result in Chrome using the IP (unsecure connection).
All of the examples are with 5.4.3.2 installed with CommandBox.
I believe I have an explanation 2 of the screenshots you provided.
In the first one, you’re going via HTTPS, but don’t have a certificate the browser trusts. Since you told the browser that it’s okay if the certificate is not valid, all the interactions still happen over HTTPS, thus the cookies with the “secure” bit set work.
In the second one, your connection is over HTTP, so the cookie data is not mixed with the request data and the server doesn’t know that you already logged in or because the cookie was never transmitted, it was never able to log you in.
My experience in Brave on Linux trying to access the site via the IP address is different than yours, as it doesn’t work for me using HTTP or HTTPS.
But you are accessing on a 127. localhost IP address. On my experiments local IPs don’t have any issue, thus I’ve said:
