XenWord Development in May 2016


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.

Replacing the 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.

Inline Feedbacks
View all comments