Issue with turning off protectCSRF

[Inxentas]

Hello everyone. I'm having a little trouble with a ProcessWire website that's hosted by some company that doesn't communicate well with me. Ergo, I'm flying blind on certain things. Imagine someone else's shared hosting provider, but not having access to it's Plesk or cPanel.

When I try to log into the ProcessWire admin, I get that message the login attempt may be forged. Okay, that's usually a fingerprinting issue. So I turned that off. No dice. I turned debugging back on. I see in my stack it's protectCSRF causing an issue. So I turn that off too... and now any login attempts redirect to /admin/?login=1. The page simply refreshes, admins are not getting into the backend. I tinkered with setting and unsetting sessionCookieSecure, but to no avail. Anyone has any idea why turning off protectCSRF redirects me back to the login page?

Thanks in advance! 

$config->sessionFingerprint = 0;
$config->protectCSRF = false;
$config->sessionCookieSecure = false;  

 

[markus-th]

Hi @Inxentas,

If disabling protectCSRF and sessionFingerprint results in a continuous redirect to the login page, it’s almost certainly a session persistence issue. ProcessWire likely cannot verify your session after the redirect, treating you as a guest again.

Here are a few things to check:

• File Permissions: Ensure that /site/assets/sessions/ is writable by the web server. If PW can't write the session file, the login will fail silently.
• Clear Browser Cookies: This is crucial. If you previously had sessionCookieSecure enabled or switched between HTTP/HTTPS, your browser might be holding onto an invalid or mismatched session cookie. Delete all cookies for this domain and try again.
• Check site/config.php for Hostnames: Ensure your $config->httpHosts array correctly includes the domain (and subdomains like www) you are using to log in.
• PHP session.save_path: If you aren't using PW's native session handler (Database), check your php.ini to see if the system's temporary directory for sessions is full or unwritable.
• Native Session Modules: If you have SessionHandlerDB installed, try temporarily disabling it in the database (table modules) to see if switching back to file-based sessions resolves the conflict.

Since you have debug mode on, check /site/assets/logs/errors.txt for any "Session save path not writable" or "CSRF" related entries that might have been logged right at the moment of the redirect.

Hope this helps!