Lucee Admin asks for password at every click

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:

  1. Installed IIS on Windows 11
  2. Created a new directory for my test website.
  3. Added an entry to my hosts file
  4. Created the new website in IIS
  5. Installed the latest version of Lucee
  6. After Lucee installed, navigated to the new website.
  7. CF tags were processing. Success
  8. Logged into the server admin using address. Success.
  9. 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 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.

Can any shed light on this?

Could you try the latest snapshot to check if the issue persists there? Please make sure to remove all cookies of your browser when you access the admin.

See ready for testing

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



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 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, 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.


1 Like

@Zackster remember that I had a similar issue with as we did the update tests? However, I’ve not experienced nothing similar with Snapshot. If somebody encounters this issue with 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?

This is with…

In FireFox:

Part 2:

In Chrome:
It logs me out.

1 Like

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.

1 Like

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 and I tested under Firefox and Brave in Linux, but last night Brave under Windows was doing the same thing.


1 Like

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 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:

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 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 is blocking.

1 Like

This is on my local:

a) My address is a loopback address. The url is resolved to 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.

@Miguel-F @andreas

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.

So, it seems that the two issues are:

Cookies not being set in an HTTP connection


Having URL Rewrites being true.