CUNY Academic Commons

A few tests show that it's working in general. If you have any additional details that might help to reproduce the problem, please share them:

1. URL from which you're logging in
2. How you are logging in (the login form on the toolbar vs wp-login.php)

The speed of the loading suggests that you're getting a cached version of the page.

Please test in an incognito/private window to see if you're seeing the same behavior. It will help to narrow down potential issues.

I tried the private window also, but it is not working either. Tried Firefox, Safari, and Google.

Yeah, it sounds like you're getting cached pages from the CDN. Something else you can try in the short term is to try from a different IP address - try a mobile connection or some other ISP.

I'll add this to my list of things to talk about with the Reclaim people tomorrow.

I was able to login via ipad.

Via ipad connected to a mobile network? Sorry, just trying to narrow down what may be happening for when I talk to Reclaim.

Yes, it was through a mobile network.

Juar noting that I was able to log in this evening without a problem

FYI - We are getting several more reports on Keeping of this problem.

Boone, there is a setting in the Litespeed Cache plugin that caches the login page. It is turned on by default. Perhaps turning this off will help with some of our users?

Thanks, Ray. I can't see this setting at a glance. Could you have a look?

Scott and others, if you get more requests of this, please share precise details. Specifically, a timestamp + info about the method of logging in, and an IP address if possible, will help me to understand the nature of the issue better.

Thanks, Ray. I can't see this setting at a glance. Could you have a look?

It's located on this admin page: https://commons.gc.cuny.edu/wp-admin/admin.php?page=litespeed-cache and on the [1] Cache tab, the option name is "Cache Login Page". I've just turned this off.

Great, thanks for that. My eyes were glazed over this morning :-D

Hi All,

I am able to login successfully on chrome and firefox and sarfari. But, i was experiencing the same issue as other users until I visited https://commons.gc.cuny.edu/wp-login.php directly.

There are ~15+ tickets in keeping about this issue. Should we advise other users to go directly to wp-login? Should we ask other users to clear their cache? Would it be helpful to ask them for more info?

Thanks for this report Laurie and for everyone dealing with these tickets. If I'm gathering correctly looking back through this ticket, Boone was asking for this in login error reports:

- Login timestamp
- Info about the method of logging in
- IP address if possible

On the "method" point, does this include things like browser, desktop v. mobile, operating system? Whether they used the Login button on the homepage or the toolbar? Anything else?

On the "method" point, does this include things like browser, desktop v. mobile, operating system? Whether they used the Login button on the homepage or the toolbar? Anything else?

Any or all of this info would be helpful.

There are ~15+ tickets in keeping about this issue. Should we advise other users to go directly to wp-login? Should we ask other users to clear their cache? Would it be helpful to ask them for more info?

Asking them to use wp-login.php is a good place to start. Don't bother asking them to clear their cache - this is not a problem with local cache. In general, I wouldn't bother asking for more info, as it's going to be hard to coax out of them the kind of detail we need to gather good data points.

I'd like to encourage members of the team to report further instances of this issue with as many specifics as possible. Here's an example:

1. On 2025-01-20 at 12:30pm EST I visited https://commons.gc.cuny.edu from the IP address 123.234.345.456. I was logged out.
2. I clicked on the 'Log In' button at the upper right on the toolbar
3. When the login panel appeared there, I entered my username and password and clicked 'Log In'
4. The page refreshed, so that I was looking at https://commons.gc.cuny.edu/ again. However, I was seeing the logged-out version of the homepage.

There is no amount of detail you can provide that will be too much for debugging this issue.

if you experience it again, please also gather the following information:

a. After logging in, go to https://commons.gc.cuny.edu/wp-admin/. Do you see the Dashboard? I expect you would: this means that you are logged in, but you are being served cached versions of the logged-out homepage
b. Do something similar with a group you're a member of, or other sites you're a member of. Share the URLs and your results
c. Check your browser cookies. Open the inspector (F12) and find the Application tab. Look for Cookies belonging to commons.gc.cuny.edu. Tell me the cookie names (not the values, which are private). Eg "_lscache_vary", "wordpress_sec_11355d9464effe58559f5faaaf2a6470", etc.

Hi - All of a sudden it seems to be working for me!

I've asked four members on Keeping to report back, but have not heard from them yet.

Thanks, this is helpful.

It looks like I'm still logged out (I am also an admin of this site, so the toolbar should have the admin options).

The toolbar is part of the page. If you're getting served a cached page, then you'll see the incorrect toolbar. The way to see if the auth cookies are set is to visit the Dashboard: https://newsliteracymatters.com/wp-admin/

Hi Boone -
I received two replies on Keeping. Both said it is still not working.

Do you think that when I went to https://commons.gc.cuny.edu/wp-admin/ (at Laurie's suggestion), that that fixed the issue for me?

Anyway, I've asked the two members for more information.

Thanks, Scott. Unfortunately, 'not working' doesn't really give enough information to do further debugging.

I do have a ticket open with Reclaim, and they're going to try to figure this out. Without specific steps to reproduce, it will be difficult, but hopefully some will trickle in here.

Do you think that when I went to https://commons.gc.cuny.edu/wp-admin/ (at Laurie's suggestion), that that fixed the issue for me?

Hard to say what "fixed" even means here, since I don't have a clear idea of what's happening. If this is a problem with cached assets, then the CDN decides when to serve you a cached page. It's possible that visiting wp-login.php manually would cause a cache purge, but it doesn't seem super likely. More likely is that the logged-out homepage just happened to expire around the time you visited wp-login.php. But this is all conjecture, based on my assumption that you are actually being logged in, but the page you're redirected to immediately afterward is a cached logged-out view.

The toolbar is part of the page.

Huh, never knew/noticed that. It's confusing to me that "Log In" in that toolbar takes you through the login process, which works, but then the toolbar doesn't change (as it does elsewhere on the Commons) to a logged-in view. All a separate issue, though, and I'm not sure what could or should be done given the edge case of mapped domains.

The toolbar is part of the HTML document. The caching layer caches the entire document, which includes the toolbar. So, if you receive a version of the document that was cached, it will contain the toolbar in the logged-out state. None of this is a bug or an issue to be concerned about, it's just a fundamental part of how webpages work (that it's a single HTML document). The problem is that you should not be receiving a cached document when logged in, where "logged in" is a technical term that means "your browser has the proper WP authentication cookies set"; when I asked you to view wp-admin, this was a way I was asking you to test whether those cookies were properly set.

Sorry for not answering that part about wp-admin. Yes, I was able to access that link directly. And thank you for the extra clarification.

In case it helps Scott or others working with affected users on this, especially trying to get more detail from them for Boone, I just wrote this to a colleague who can't log in. It's basically and adaptation of what Boone asked us to gather before:

If you still can't log in, I have some more details to request from you. It will be a bit of a pain to collect them, but they could really help get to the bottom of this. We would like to see:

- The exact date and time of the new unsuccessful login attempt.
- Your IP address (use whatismyip.com or similar).
- Your exact steps that led to the unsuccessful login. This would be something like this:

"I visited https://commons.gc.cuny.edu. I was logged out. I clicked on the 'Log In' button at the upper right on the toolbar. When the login panel appeared there, I entered my username and password and clicked 'Log In'. The page refreshed, so that I was looking at https://commons.gc.cuny.edu/ again. However, the page looked the same as when I started, while logged out, I wasn't seeing the personalized view that usually loads when I successfully log in."

- After the unsuccessful login attempt, go to https://commons.gc.cuny.edu/wp-admin/ directly. Paste it right into the browser address bar. Do you see the Dashboard?
- Check your browser cookies. In Chrome, in the top menu bar, go to View > Developer > Javascript Console. Then change tabs in the window that appears from Console to Application. There should be a left-sidebar option that says Cookies. Look for Cookies belonging to commons.gc.cuny.edu. Tell me the cookie names (not the values, which are private). Eg "_lscache_vary", "wordpress_sec_11355d9464effe58559f5faaaf2a6470", etc.

- Then do the same thing with this group and this site, which I know you should have access to. Do these load as they should?

https://commons.gc.cuny.edu/groups/art-7196g-journey-to-wakanda/
https://wakanda.commons.gc.cuny.edu/wp-admin/

- After loading each of these two links, check and include the cookies as above for these as well.

Note to swap out the two links above with other groups/sites that the person should be able to access to see if they are in fact logged in even if the homepage is not suggesting that they are. I found a private group in this case, and any site to which they should have dashboard access is good.

Hi All,

Once the issue was resolved for me, I am unable to recreate it in any browser or on any device. Some reports from users when I asked them to follow the steps colin outlined above and report back (apologies for the lack in info, I asked for them to be as detailed as possible but this all we got back on the help desk):

User1

at about 8:30am today—Prior to my emailing you: After trying to login and getting the password reset request, I reset the password, and then could not log in. I cleared out all the cookies, the cache, history, made sure the pop up blocker was off (I'm on Chrome, OS is latest Windows 11 update as of yesterday). I just tried again and it let me in at about 9:35am - I didn't do anything new, just tried again a few times after you told me they were working on the issue. It seems to all be working fine now.

User 2:

I’m not sure what resolved it but I was able to login somehow this morning after some attempts and playing with it. I don’t know what I did to make it work exactly. I’ll pay closer attention and share the info you requested if I’m locked out again.

These user experiences seem similar to mine - once I manually went to /wp-admin or /wp-login.php, I never experienced the log in issue again.

Thanks for the data points, Laurie. I'm unsure how or why a specific event would cause the problem to go away once and for all. Perhaps all this "reset" stuff sets a specific cookie which, once set, gives Litespeed the appropriate information for caching?

That is perfect, Laurie. Please also provide other information about URLs, specific steps taken to log in, etc. Thanks!

Thanks for circling back, Laurie.

I just walked through the password reset process and didn't have any problems.

then gets redirected to the commons with the message "link not valid".

I don't see a message that says "link not valid" as part of this flow. There are two types of messages one might see:
- "Error: Your password reset link appears to be invalid. Please rquest a new link below."
- "Error: Your password reset link has expired. Please request a new link below."

Do either of those ring a bell? They would indicate different sorts of problems.

Or perhaps it's neither of these. Your screenshot only shows the "Error: The password you entered for the email address ... is incorrect". Is that the "link not valid" text you saw?

Not sure if this is a helpful data point, but I used the email address from your screenshot to identify the user. Comparing the password hashes from the user's signup (what was entered during the registration process) and the user's current account, it looks like they are the same. This suggests that a password reset never took place.

It was first option "Error: Your password reset link appears to be invalid. Please rquest a new link below."

We also ahve another user on the help desk, brucenyc, reporting a similar issue

attempted to log in on 1/21/25 at 1:27 p.m. My IP address is 74.64.137.103. I received this error message:

"Error: Your password reset link appears to be invalid. Please request a new link below."

I tried the second method of going directly to /wp-admin/ page directly but could not log in.

I have asked him to run through this process again and submit screenshot of pages with this information and cookies screenshots. Perhaps we need another tickets for the pw reset issue?

I have asked him to run through this process again and submit screenshot of pages with this information and cookies screenshots. Perhaps we need another tickets for the pw reset issue?

Yes, please open a separate ticket. It doesn't seem like the same issue to me.

When you open that ticket, can you please clarify (if you know) exactly what the user did to see this message? Did they try to reset their password, or is this what they saw after an attempt to log in?

I was wondering if Laurie's above screenshot of cookie info from her first post this morning was helpful, and if that's something we should still be trying to gather from users, especially because many of them start troubleshooting and then the login suddenly works.

We can keep working with people on the detailed info, but I thought I'd try to ease the support team's load wherever we can.

Boone, I was also wondering if you could help parse for the team the LiteSpeed and other changes that Reclaim is making in our separate threads with them. Is there anything new to tell or ask users as a result? Even though we haven't isolated the login issue specifically yet, are Reclaim's latest changes a potential workaround for or way of neutralizing the issue?

FYI - I asked 5 members for more debugging info but have not heard back from any of them.

The cookie info from this morning is not helpful, but mostly because that issue was not caused by caching or anything to do with cookies. See #21828 for more details.

I don't have anything from Reclaim regarding cache config that would be useful for users. The end goal is still to have it "just work". There should be no need for user workarounds. Chris from Reclaim just made some config changes, so the best we can do at this point is to see whether the reports continue to roll in. If we get more reports (after 15:28pm EST), please let me know here so that I can know that the problem is still occurring.

Thanks for this, Colin.