• Hi,

    I have implemented a plugin that replaces the built-in authentication with checking authentication from another application I have.

    I followed instructions from http://ben.lobaugh.net/blog/7175/wordpress-replace-built-in-user-authentication and basically the code I have is:

    add_action( 'init', 'my_auth_init' );
    
    function my_auth_init() {
        add_filter( 'authenticate', 'my_authentication', 10, 3 );
    }
    
    function my_authentication( $user, $username, $password ){
        /* Retrieve correct user ID  */
        $user = new WP_User($ID);
        if( $user->ID == 0 ) {
            $user = new WP_Error( 'denied', __("<strong>ERROR</strong>: Not a valid user for this system") );
        }
        return $user;
    }

    I got it to work with 3.8, so that the user did not see the login screen at all, when logged into the other system. But after upgrading to 4.0 it seems to force showing the login screen.

    I’ve tried debugging this, and it seems to me that the function auth_redirect in wp-includes/pluggable.php sets the reauth parameter true when redirecting to wp-login.php. And wp-login.php gets the user my custom authentication returns in row 766 $user = wp_signon( '', $secure_cookie );. But after that, where I would expect it to redirect back to the page the user requested, it checks both the user and $reauth in row 791 if ( !is_wp_error($user) && !$reauth ) { and since reauth is set to true, it will not redirect, and instead shows the login form.

    Am I missing something here? is there some filter I should set to disable the reauth, or to set the cookies before the redirection completely? Or does the user necessarily go to the login page?

Viewing 4 replies - 1 through 4 (of 4 total)
  • Hi Rancca,

    I copy/pasted your code and replaced the function body with a die() and it died instead of showing me the login form.

    Is there anything else on the site that is messing with the authentication?

    Moderator bcworkz

    (@bcworkz)

    Hey Ben – Your attention to this is appreciated but it appears the issue is not that Rancca’s function is not being called, the issue is the login form on wp-login.php (starting line 865) is being displayed because the redirect is failing due to $reauth being true.

    Rancca – Your preliminary investigation was very helpful, thank you! If the remote authentication is successful, one should always call wp_set_auth_cookie() (I think, at least if $_REQUEST['reauth'] is set one should). That should technically allow the redirect to occur, the problem is $reauth has already been set by the time the authenticate hook fires and wp_set_auth_cookie() can be called.

    I suppose one could use the ‘login_form_login’ action to unset $_REQUEST['reauth'] so that $reauth will always be false. But that would mean the state cannot be checked in the ‘authenticate’ callback. Either store the value in a transient or just blindly set the auth cookie on authentication no matter what.

    This all is on a quick read. There may be critical ramifications I’m overlooking. A careful analysis and testing is called for, you do not want to get this wrong. I’ve suggested a possible approach, but it’s your site. You are responsible for it’s security, not me, so don’t take my word for anything… investigate!

    Thread Starter Rancca

    (@rancca)

    Hi,

    Yes, I got a version working with just unsetting $_REQUEST[‘reauth’] in ‘login_form_login’, and always setting the auth cookie on authentication. I naturally need to investigate more to ensure security and refine the logic, but this helps me immensely in getting forward.

    Thank you very much for the help!

    Moderator bcworkz

    (@bcworkz)

    You’re most welcome. I don’t think I could have found the solution without your initial analysis. Team effort!

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Custom authentication issue with wp 4.0’ is closed to new replies.