Question:
I have 2 different websites running SilverStripe on a VPS (one running SS4.7.2, the other SS3.6). Both have been working well for several years, but the SS3.6 installation suddenly stopped allowing logins to the CMS (no changes were made to files on the server and when I download a backup of the database to test on my local machine, login works fine and gives appropriate error messages for incorrect entries).
The problem: SS3.6 installation on server will simply refresh the login page (without logging in) when any user tries to login - no error messages are given for incorrect entries, same behaviour on different browsers/devices and same problem if reset password option is used (with no email sent). The last successful login occurred 3 days ago and also correctly triggered a password reset link. I have tried rolling back to an earlier backup of files on the server, but am still getting the same problem. I cannot run dev/build as it requires me to login and even admin logins just refresh the page.
I suspect that a server config file or SS log files may be causing the issue, but have no idea where to start looking or how to test for this to pinpoint the issue. Any tips on debugging this and fixing it would be greatly appreciated!
Do you see anything in the webserver logs? Which exact Silverstripe version are you using? Which PHP version? On which webserver? What are the exact HTTP responses you are seeing? HTTP-200, HTTP-300, others? You can use the network tools on your browser to check that.
1 Like
Without wishing to be too obvious, it sounds like something has changed on your server. Do you manage it yourself, or is it via a hosting provider?
The issue feels like a sessions problem, so that’s where I’d start looking. The type of things I’d be looking for:
- Changes in PHP configuration
- Disk space
- File permissions
- Some bigger change in hosting spec, such as the introduction of a new proxy or load balancer
Have you tried using an incognito / private window?
As ntd says, have a good look at the network tools to see if the right cookies are being set in the request / response. You can compare against your local copy, since that’s working.
1 Like
@Tim and @ntd Many thanks for your help and suggestions.
Have managed to resolve the issue. I already suspected it was a server problem, so your comments helped reinforce this. Was getting same result on private window and as my VPS is hosted (ie. not managed by me) I had limited control over that side of things other than via cPanel and WHM.
I shared your suggestions with the hosting provider and they found an error with the session path:
[28-Jul-2022 09:53:47 UTC] PHP Warning: Unknown: open(/var/cpanel/php/sessions/ea-php56/sess_su4sjpe6sq04tb69ktg68cqge5, O_RDWR) failed: No such file or directory (2) in Unknown on line 0
[28-Jul-2022 09:53:47 UTC] PHP Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/cpanel/php/sessions/ea-php56) in Unknown on line 0
The session.save_path was set as /var/cpanel/php/sessions/ea-php56 but that folder doesn’t exist.
It looks like it was set as that path for a long time. Most likely an automated server update removed the sessions folder recently with PHP 5.6 not being on the server.
The session.save_path setting is now updated to: /var/cpanel/php/sessions/ea-php70 and the login seems to work now.
The root cause is it was set to the wrong folder and should be good now with it set to the valid one for sessions under PHP 7.0.
Hopefully the above will be helpful to someone else with a similar problem in the future. Once again thanks so much for the quick replies and suggestions 
2 Likes