dominic_ks

Thanks for getting back to me, I have created a bug report on GitHub:

• https://github.com/Yoast/wordpress-seo/issues/21596

Hey @rockfire, thanks for the very quick turn around, can confirm fixed in the latest version. Using the CLI to flush caches programmatically in Cypress tests, very handy!

It would seem reasonable to do that, we can check with the other contributors, since there may be a convention on how to handle this. I’ve created an issue on GitHub to discuss:

• https://github.com/usefulteam/jwt-auth/issues/128

@rtinchev Thanks, just wanted to make sure I’m understanding that. I’m not sure what the correct behaviour should be here, we may need to discuss on GitHub. What would your expectation be? Ignore the refresh token if login credentials have been provided?

OK, so do you agree that the answer to my question is yes? That this error message is returned if you supply both a refresh token cookie and login credentials in the same request?

Are you all sending username and password and a refresh token cookie in these cases?

That error is triggered in one of two places, depending on whether you are requesting a token or validating one, but both are triggered if the secret key can’t be read from a line like this:

$secret_key = defined( 'JWT_AUTH_SECRET_KEY' ) ? JWT_AUTH_SECRET_KEY : false;

From what you’ve pasted, it looks like you have set the secret key, so perhaps you can do some debugging from a plugin file or functions.php file to see if that constant is being set?

Yes, you can do something like this:

$user = get_user_by( 'ID' , $user_id );
$auth = new \JWTAuth\Auth;
$token = $auth->generate_token( $user );

• This reply was modified 4 months ago by dominic_ks.
• This reply was modified 4 months ago by dominic_ks.

Hi @alexrollin,

Yes, I am indeed referring to the permission_callback param. I will give a couple of examples here, though I would also say that giving support for that specifically is not within the scope of this plugin, the plugin is here to provide a method of authentication only.

For custom routes, this is simple, just pass is_user_logged_in to the permission_callback:

<?php
add_action( 'rest_api_init', function () {
  register_rest_route( 'myplugin/v1', '/author/(?P<id>\d+)', array(
    'methods' => 'GET',
    'callback' => 'my_awesome_func',
    'permission_callback' => 'is_user_logged_in', // this will ensure only logged in users can access
  ) );
} );

As for the built in routes, I’ve not done this before, but found a couple of examples here you can try:

• https://paulund.co.uk/only-allow-access-to-rest-to-logged-in-users
• https://gist.github.com/khromov/471661daaa36553d297065930eaa5252

Hi @alexrollin. Thanks for getting in touch, though I have to say I’m not sure what the issue is that you’re reporting here.

It does mean that when I make a REST request it returns the REST response like a bad JWT config.

In my case, it returned the same REST response as before.

Are you saying your issue is that it doesn’t return an error, and you are expecting it to? If this is the case, can you confirm if the routes you are testing require authentication?

One of the major changes in V3 is the removal of the whitelist. Previously, the auth header would have been checked for all routes unless they are whitelisted. Now, the auth header is only checked if the route requires an authenticated user.

Hello @abhay-raj,

The /token endpoint only accepts a POST request, it looks like you are using GET there.

You’ll also need to provide the username and password in the request body unless you’re including a refresh_token cookie.

Thanks,

• This reply was modified 6 months, 1 week ago by dominic_ks.

Hey @maidot No problem, thanks for confirming you got it sorted!

Hello,

Thanks for that, yes, a couple of tweaks to be made to our automated deployment process from GitHub. I’ve updated that manually just now, so hopefully that resolves it for you.

Thanks,

Well, thank you very much @philsola! Appreciate you taking the time.

Hello,

Can you clarify what you mean by this question? If you are referring to the fact that the endpoints for this plugin include /v1/, that’s just a reference to the fact that those endpoints are the first version of the API for this plugin, it doesn’t have anything to do with the /v2/ you see in the core API endpoints from WordPress.