1

There are many questions and answers on external authentication and some code prior to WordPress 4.0 need some tweaking to get them to work. For example, adding a fourth parameter to the wp_set_auth_cookie will stop some strange issues. However, session_tokens are not destroyed and the meta value is repeatedly added to after each login (leading to a huge mess).

To get WordPress caching plugins to work properly, then the session_tokens need to work properly: created on login and destroyed on logout.

The following code will login any user in the external database.

add_action( 'after_setup_theme', 'xenword_login', 10, 1 );

function xenword_login( $username ) {

add_filter( 'authenticate', 'allow_programmatic_login', 10, 3 );    // hook in earlier than other callbacks to short-circuit them
$user = wp_signon( array( 'user_login' => $username ) );
remove_filter( 'authenticate', 'allow_programmatic_login', 10 );

    if ( is_a( $user, 'WP_User' ) ) {

        wp_clear_auth_cookie();
        wp_set_current_user( $user->ID, $user->user_login );
        wp_set_auth_cookie( $user->ID, true, is_ssl(), true );

    if ( is_user_logged_in() ) {
        return $user->ID;
    }
}

return false;
}

Then an allow_programmatic_login is placed in the same file.

function allow_programmatic_login( $user, $username, $password ) {

    $visitor = XenWord::getVisitor();
    $user_id = XenWord::getVisitor()->getUserId();

    if ( $user_id > 0 ) {
        $username = $visitor['username'];
        return get_user_by( 'login', $username );
    }
}

Fantastic except an administrator, editor, etc cannot go to the dashboard because the cookie will not be validated. Replacing the wp_validate_auth_cookie will get the accounts to have access but then caching plugins will not load properly.

After tinkering for a few days (year), I discovered recently that the verify( $token ) causes the issue.

$manager = WP_Session_Tokens::get_instance( $user->ID );
if ( ! $manager->verify( $token ) ) {
    do_action( 'auth_cookie_bad_session_token', $cookie_elements );
    return false;
}

This led me to look at the database and see that the session_tokens were being created on login but not destroyed on logout.

My question: Has anyone identified and overcome this issue because simply using the following logs in the account but no session_tokens are created.

    wp_clear_auth_cookie();
    wp_set_current_user( $user_id, $user->user_login );
    wp_set_auth_cookie( $user_id, true, is_ssl(), true );

    do_action('wp_login', $user->user_login );

This leaves me using the authenticate option but the session_tokens are not destroyed. Any suggestions?

  • 1
    Get all session tokens of user: $sessions = WP_Session_Tokens::get_instance( $user_id ); Destroy them all: $sessions->destroy_all(); Maybe this will work. :-) SOURCE – N00b May 5 '16 at 18:46
  • Your shor tcircuiting WP normal authentication process and handling it yourself. My recommendation is to remove the after_setup_theme hook, remove xenword_login function, only have remove_filter( 'authenticate', 'allow_programmatic_login', 10 ); and the allow_programmatic_login() function. Stop playing around with WP cookies. – user42826 May 5 '16 at 21:56
  • As stated session_tokens in usermeta are not being destroyed on logout. This leads to many issues. I'm simply trying to get external authentication to work - and linked in OP to the page with different answers. None work. Maybe someone who has actually tried external authentication since 4.2 can answer. – LPH May 14 '16 at 17:11
0

Here is the final code to get sessions to write to the usermeta and delete on logout. This code works with WordPress 4.5.2. The code is for user_id information only.

add_action( 'after_setup_theme', 'new_login' );

function new_login() {

    $user_id = ''; // Change your code to grab user_id from external source

    if ( $user_id > 0 && ! is_user_logged_in() ) {
        $user = get_user_by( 'id', $user_id );

        wp_clear_auth_cookie();
        wp_set_current_user( $user->ID, $user->user_login );
        wp_set_auth_cookie( $user->ID, true, is_ssl() );

        if ( is_user_logged_in() ) {
            return true;
        }

    } elseif ( $user_id == 0 && is_user_logged_in() ) {
        wp_logout();
        wp_set_current_user( 0 );
    }
}

There are a couple of key issues. First, the conditional ! is_user_logged_in() must be included with the check for a user_id greater than zero. Next, the wp_set_current_user(0) must follow the wp_logout() in order to avoid a refresh.

I hope this helps others trying to get external authentication working with user_id information only.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.