Introduce WpAppNotifier

[oguzkocer]

Introduces WpAppNotifier trait with the requested_with_invalid_authentication function. This will get triggered by request executor if the response status is 401 and the newly added is_valid_authentication returns IsValidAuthenticationResult::Unauthorized.

The new is_valid_authentication function makes a request to GET /wp/v2/users/<user_id>)/application-passwords/introspect and return either Authenticated, Unauthorized, ErrWpApiError or ErrRequestExecutionError. We only return Authenticated or Unauthorized if we parse the response and find what we are looking for.

Also, each request executor now has a has_valid_authentication function which internally calls the is_valid_authentication to make it easy to manually check the authentication state.

[crazytonyli]

For the purpose of finding out whether the current application password is still valid, only a 401 status code check is not enough, since not all 401 responses mean that an invalid application password is used.

We'll probably want to use a stricter check like

fn is_unauthorized_error(response: &WpNetworkResponse) -> bool {
    if response.status_code == 401 {
        if let Some(original_error) = WpError::try_parse(&response.body.clone()) {
            return original_error.code == WpErrorCode::Unauthorized;
        }
    }

    false
}

[oguzkocer]

I don't think we always get back WpErrorCode::Unauthorized. For example,

> curl --user [email protected]:invalid "http://localhost/wp-json/wp/v2/users?context=edit"
> {"code":"rest_forbidden_context","message":"Sorry, you are not allowed to list users.","data":{"status":401}}

So, at least for now, I have changed the condition to be true for both WpErrorCode::Unauthorized and WpErrorCode::ForbiddenContext in 8085903. Let me know what you think!

[crazytonyli]

Maybe we should check whether the HTTP response status code is 401 instead? So far, it looks like the core would always return a 401 status code, but may return a different {"code": ...} in the response JSON.

[oguzkocer]

The initial implementation was checking for 401, but I tried updating it as per your previous suggestion. I agree though, I think we should only check the status code since we are going to make a request to check if the application password is valid.

[crazytonyli]

Ah right. The original approach of creating WpAppNotification from HTTP response probably won't work. But I see it's updated to invoke a callback after application password check. 👍

[crazytonyli]

This test set up is not suitable for the purpose of detecting an invalid application password. We should pass a hard-coded username and invalid application password pair here.

[oguzkocer]

Addressed in d3b5895.

[crazytonyli]

Should this be more specific, like authentication_becomes_invalid?

[oguzkocer]

Addressed in 6bbb9bb.

[oguzkocer]

becomes_invalid may be a little misleading because we currently don't check if the authentication is valid when we first build the client. Maybe we should go with requested_with_invalid_authentication?

[crazytonyli]

Sounds good to me!

[oguzkocer]

Addressed in a93523c.

[crazytonyli]

Technically, receiving a RequestExecutorError does not mean the request is unauthorized. I wonder if we should explicitly check the WpErrorCode instead here?

[crazytonyli]

As discussed above, these if statements can be changed to if is_unauthorized_request == 401 && #crate_ident::is_unauthorized_request(...) {