Login Loop - Can't login with any existing user credentials

alcoma

Has anyone experienced being logged out of Providence only to have login attempts fail with no errors or anything, just the login window refreshed ? I tried logging in with different user accounts and the Login window just keeps looping...

seth

Make sure you are using https requests, and make sure app/tmp and all contents in that directory are writeable by the web server.

alcoma

Thanks. I can confirm ssl and tmp is writable. I just upgraded to C/A 2.0.11 since we're on php 8.2, and after updating composer and schema and getting the new login window, this issue is persisting.

alcoma

I wanted to add some more details to this as the issue persists:

Upgrading to latest release didn't go well so I reverted to a recent backup of providence then updated from 2.0.4 to 2.0.9.
Things seem ok so far except this login loop is ongoing. After A Lot of troubleshooting I can rule out that this is not related to: browser, session, or cookie issues, Cloudflare interference, php session settings or form submission failure. I can say though that the login loop is consistent and silent (no visible errors) but the ca log shows both failed and successful logins for my user, though I never actually get logged in or get an error. ? It's a constant redirect. It has been a few days since I've been able to access Providence because of this. Any help so appreciated.

monica

alcoma clear cache on server and in browser. Are you using Apache or nginx? clean_urls turned on? After the redirect have you tried going directly to /dashboard ?

alcoma

I have tried all those. Clean urls are set to '0'. We're on Apache. I can't access dashboard in any way.
The url after loading 'oursite.org/ca' looks like:
https://oursite.org/ca/index.php/system/auth/login?redirect=https%3A%2F%2Foursite.org%2Fca%2Findex.php%2FDashboard%2F_default

seth

I would try deleting the vendor/ directory in its entirety. remove the composer.lock file and run composer to rebuild the vendor/ directory. I would also double-check file permissions. A common cause of the behavior you describe is incorrect file permissions on a sub-set of files within app/tmp, while app/tmp itself has correct permissions.

alcoma

Thanks Seth. I did try all the above, but no change. I also dbl checked app/tmp permissions and cleared tmp with no change.

Upon inspecting the logo image that doesn't load on our login page I see this error:

Refused to load https://static.cloudflareinsights.com/beacon.min.js/v8c78df7c7c0f484497ecbca7046644da1771523124516 because it does not appear in the script-src directive of the Content Security Policy.

Am wondering if something needs to be added to index.php under security headers that might help this ?

We never had issues with Cloudflare services interrupting our work in C/A. Even when utilizing their under attack mode (a time we were getting 1Mil bot hits to our site every week). The last time I was able to login was before the first git update I tried, then after I was logged out and couldn't log back in.

(* re img, it is indeed in the correct place in the theme folder and called in app.conf)

Another note re: Php is that we are on 8.2; when locating directory of session files using
php -i | grep session.save_path
I got .../php/sessions/ea-php82 but the directory was empty. (?)

alcoma

Update: This matter is now closed. Turned out there was some kind of redis cache collision... and defining a database # for 'CA_REDIS_DB' in ca/app/helpers/post-setup.php cleared up the login issue.