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.
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.
Here are the steps I took that got me to the point of issue:
Installed IIS on Windows 11
Created a new directory for my test website.
Added an entry to my hosts file
Created the new website in IIS
Installed the latest version of Lucee 18.104.22.168
After Lucee installed, navigated to the new website.
CF tags were processing. Success
Logged into the server admin using 127.0.0.1:8888/lucee/admin/server.cfm address. Success.
Logged into the server admin using the new website url: http://test.local/lucee/admin/server.cfm address. Success
10: Installed the URL Rewrite 2.0 module for IIS
11: Attempted login to the server admin 127.0.0.1:8888/lucee/admin/server.cfm address. Success.
12.Logged into the server admin using the new website url: http://test.local/lucee/admin/server.cfm
a. Login was successful
b. However, all the links on the admin screen redirected me back to the login page
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.
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 22.214.171.124 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 126.96.36.199-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.
@Zackster remember that I had a similar issue with 188.8.131.52 as we did the update tests? However, I’ve not experienced nothing similar with 184.108.40.206 Snapshot. If somebody encounters this issue with 220.127.116.11 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?
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 18.104.22.168 and I tested under Firefox and Brave in Linux, but last night Brave under Windows was doing the same thing.
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.