Development of XenWord 3.0 began almost one year ago, and while the beta milestone has been reached, a sticking point is now the new authentication system working properly with creating and destroying sessions kept in the WordPress _usermeta table.
WordPress 4.0 introduced new security measures for login, leading to an issue with using
wp_set_auth_cookie in the XenWord login files. In particular, a nonce error happened whenever an administrator attempted to activate or deactivate a plugin. To avoid the error, a cookies.php file was created which contains a replacement for
wp_validate_auth_cookie means caching plugins will not properly read the cookies and not function properly. This is a major draw back for many customers trying to tune their site performance.
The hardest part has been discovering the lines of code creating a problem for the new authentication system. It turns out the verify token line is the issue. Commenting it out allows a user to login, get to the WordPress dashboard, and administrators can activate and deactivate plugins.
[pastacode lang=”php” path_id=”949859df6af136b3dc809f0dd524e0a9″ file=”” highlight=”” lines=”” provider=”gist”/]
It’s best to figure out how to not replace the function, and so after several more days of tweaking and pulling out hair, and after reading the WordPress code a little more, a fourth parameter was added in the wp_set_auth_cookie line. An important line of code now reads
wp_set_auth_cookie( $user->ID, true, is_ssl(), true );
With these code changes the authentication system works and a session_token is created in the _usermeta table. However, this token should be destroyed after logging out and this isn’t working.