plugin development - External Authentication, session_tokens not destroyed on logout

admin管理员组

文章数量:1289879

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?

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?

• plugin-development
• hooks
• login
• session

Share Improve this question edited Apr 13, 2017 at 12:37 CommunityBot 1 asked May 5, 2016 at 18:24 LPHLPH 80811 gold badge1111 silver badges2525 bronze badges 3

• 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 Commented May 5, 2016 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 Commented May 5, 2016 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 Commented May 14, 2016 at 17:11

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 1

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.

本文标签： plugin developmentExternal Authenticationsessiontokens not destroyed on logout