0

I have been using a site for the past few years which I wrote myself in PHP. The site was to create events for people to join and take part in, with different features in them for different events. Some were on subdomains of the main domain and some were on separate domains altogether. All of them were hosted on the same server and their account details held in the same MySQL database.

I am now moving to a WordPress site using WooCommerce to fulfill orders and entries so all future events will go through there. I know that the users will have to create a new password when they first use the WooCommerce/WordPress site as all of their details will be in a new database. Now I still have events that I wish to leave running which are not built around the WordPress site.

What I am trying to work out is;

  1. How can I create a login script for the non-WP sites that will be able to login against the details from the WP user database? I don't understand how I too hash the details the same way as WP and confirm they are correct. Any links that can explain the hash that WP uses that I can understand?

  2. What are the cookies/sessions that WP and WooCommerce set upon login so that I can search for them on the non-WP sites? If they log in on the main site I'd like for them to not have to log in again on the older sites.

I have been searching for answers all day and have only found little snippets of how parts might be possible. Changing some of the cookie settings in WP_config to set them for multiple sites has been one of them.

Any advice would be a huge help!

Eric

1 Answer 1

0

WordPress's code to verify passwords is wp_check_password. You'll see that this uses phpass:

require_once ABSPATH . WPINC . '/class-phpass.php';
// By default, use the portable hash from phpass.
$wp_hasher = new PasswordHash( 8, true );

$check = $wp_hasher->CheckPassword( $password, $hash );

which is class-phpass.php in the WordPress code which at first glance looks like it has no WordPress function dependencies and you can just take the whole file.

Note though that you can also modify this code to match your existing passwords if you have them available to WordPress somehow: you could either

  1. add your own authenticate hook, like the default wp_authenticate_username_password

    // Default authentication filters.
    add_filter( 'authenticate', 'wp_authenticate_username_password', 20, 3 );
    

    that would check your own password hash and return a populated WP_User object if it matches

  2. hook the check_password filter, which is called at the end of wp_check_password after it has tested the hash:

    /**
      * Filters whether the plaintext password matches the encrypted password.
      *
      * @since 2.5.0
      *
      * @param bool       $check    Whether the passwords match.
      * @param string     $password The plaintext password.
      * @param string     $hash     The hashed password.
      * @param string|int $user_id  User ID. Can be empty.
      */
     return apply_filters( 'check_password', $check, $password, $hash, $user_id );
    

    If the $check value passed in is false then that means the password didn't match the hash using WordPress's algorithm: you could then test the password against the hash using your existing logic and return true if it matches that.

That way your users could keep their existing passwords. Your code that matches the existing hashes could then write a new-style hash into the user object if you wanted since it has the clear password to hand, or you could just keep matching the existing passwords.

The code to check the cookies is a bit more involved, alas. It's wp_validate_auth_cookie. If you follow this through, you'll see that

  • the cookie is called wordpress_<hash> or wordpress_sec_<hash>, depending on whether you're using HTTPS or not, where the hash part is the MD5 of the site URL
  • it is split into four pipe-separated parts
    • username
    • expiration date
    • session token - must match a value in the 'session_tokens' wp_usermeta for the user
    • authenticated hash - an MD5-HMAC of the other three components, plus four characters from the user's password hash (so that cookies are invalidated on password changes), using either AUTH_KEY or SECURE_AUTH_KEY from wp-config as the HMAC key

I suspect you'd do best extracting the relevant parts of the WordPress code rather than trying to reimplement this, or even calling out to the WordPress instance somehow.

However once again you can extend WordPress to accept your existing cookies too: in this case you want to hook determine_current_user.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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