Support » Developing with WordPress » Check if Application Password is correct

  • Resolved Beda

    (@bedas)


    I am fiddling with a Custom REST POST endpoint.

    I have setup a custom route with register_rest_route.
    I have the route working, and the response as well properly working when a POST request is made to the custom endpoint.

    I see there are two ways of “authenticating” the request.

    1. In the callback of the register_rest_route $args simply check on some “hardcoded” token. For example the below, assuming a POST request with an authorization:token header value.

    
    $token = 'token';
    $auth_token = $req->get_headers()['authorization'][0];
    if ( $token != $auth_token ) {
    // handle error
    }
    

    2. Why not use permission_callback with Application Passwords? I like this much more. Solution #1 to me seems a bad hack, mainly because I have to save the token in my code, rather than _only_ as a password for an existing user, in the database.

    So I setup a user in WP, added an Application password for that user, now I want to check if when a POST request is made to the custom endpoint, the request authorization header does have the User ID/Email AND a matching application password.

    I found that I can get the Application password using

    
    $app = new WP_Application_Passwords();
    $pwd = $app->get_user_application_password( get_user_by( 'email', 'test@test.mamp' )->ID, 'UUID-here' );
    

    The problem is the password returned is one way hashed. How would I compare this retuned one-way hashed password to whatever the POSTer sends as authorization in his header?

    Or perhaps I am doing all this wrong?
    I basically want to use the Application Passwords like an “API KEY”, which should not be saved in the codebase but as DB value _only_, just like Passwords, and be connected to existing users on the WP site.

    Hope it is not too confusing. Thanks for inputs!

Viewing 2 replies - 1 through 2 (of 2 total)
  • Moderator bcworkz

    (@bcworkz)

    Hi Beda,

    Wouldn’t you get another hash of the same password and compare it with that coming in with the request? Just as you’d verify any nonce? I’d assume the hash becomes invalid after 24 hours just as a nonce would. In that way it’s not like an API key which doesn’t normally expire. I assume the same hashing mechanism is used, I’ve not investigated further.

    Thread Starter Beda

    (@bedas)

    Hi @bcworkz – sorry the late reply.

    I did move on with another approach on this issue here, I think I had overthought the approach and was able to resolve it without the app-pwd feature.

    Thus, closing here – sorry to “waste” your time without even trying what you suggest, I am pretty sure you are right thou.

Viewing 2 replies - 1 through 2 (of 2 total)
  • You must be logged in to reply to this topic.