Conflict with Softaculous admin login

[chrishallx]

On a shared hosting provider using a Softaculous-installed instance of WordPress, installing and enabling SQLLite3 Object Cache breaks the ability to use their admin login bypass (Wordpress redirects to the homepage and WP Cerber will show "deleted invalid cookies" as an underlying action).

Logging in manually via /wp-admin still works in this case, and all site functionality appears normal (and snappier) until logging out and then trying to log back in via the cpanel/Softaculous link.

Starting an issue here since I could not find an instance of this particular gremlin reported anywhere. WP 6.8.1, igbinary, APCu extensions active, PHP 8.4. When more details are needed let me know and I'll re-enable temporarily to pull them.

[OllieJones]

Asking on the Softaculous forum ...

https://www.softaculous.com/board/index.php?as=yu6vgqniu2jsmj5jekb7jxjfkizx30zi&tid=20415&title=WordPress:_Incompatibility_between_SQLite_Object_Cache_and_Softaculous_Login

[OllieJones]

landonpierce on the Softaculous forum offered this:

https://www.softaculous.com/board/index.php?tid=20415&tpg=1#p60305

It might not be cookies directly, but Softaculous’ auto-login flow depends heavily on very short-lived usermeta and auth-related lookups that normally bypass persistent storage. Even though WordPress doesn’t persist nonces or auth tokens, Softaculous creates (and expects) fresh user session state at the moment the bypass link is clicked. If the object cache is persisting any part of the user’s last session especially get_user_meta(), cached capabilities, or the WP_User object it can cause WP Cerber to treat the Softaculous-issued cookies as “invalid” because the underlying user state doesn’t match what WordPress recomputes during a normal login. In shared hosting, this becomes more visible because Softaculous and WordPress aren’t always running under the same PHP worker, so stale cache keys linger longer. A possible fix on the plugin side would be to avoid caching usermeta and capability lookups during authentication requests. Checking for wp-login.php, wp-admin, or is_user_logged_in() during the login handshake only might be enough to force fresh reads on those keys without disabling caching globally. Not a perfect solution, but it narrows the issue to where Softaculous’ bypass actually fails.WordPress: Incompatibility between SQLite Object Cache and Softaculous Login
landonpierce

[OllieJones]

I haven't been able to reproduce this issue. If you have any more information that would be helpful.