Dave McHale

Hi @ipajen Thanks for the report. What version of WordPress and what version of this plugin are you running? Also, are you aware if any of your other plugins are changing the version of jQuery running on your site that typically ships with WordPress?

Hi @sadesades Sorry to hear you’re having trouble. Have you tried enabling wp_debug to see if you’re getting any errors or warnings on your site? What rules do you have defined in your admin area, is this just allowing all users to access the CF7 endpoints or do you have a number of other user roles defined? The permissions check should be imperceptible to speed of accessing endpoints and I haven’t heard any reports similar to yours before, but I’m happy to take a look if you can provide me with any additional details. Thanks!

Thanks for the detailed report @brianrshim ! Will definitely look into this.

I’m happy to hear that it doesn’t seem to be affecting any functionality, but the goal is definitely to prevent all errors/warnings/notices

I will update this thread once I have something to report. Cheers!

Thanks for the 5* @aparsley and glad the plugin does what you need!

Hi @burnagielk

I attempted the upgrade this morning and can confirm that it no longer crashes the website upon update ??

Thanks again! I’ll make this as resolved. Take care

Thanks for the 5* review @maximepasquier , happy to hear the plugin does what you need!

Appreciate the 5* review @kayart, thanks for using the plugin and glad it does what you need!

Thanks for using the plugin @citking and for the 5* review! Glad you enjoy it

hello @burnagielk

Don’t want to be a nag, but any updates on this? Right now this pending plugin update is a ticking bomb ready to go off if my client were to try and upgrade plugins on their own (which they are known to do), so I’m hopeful for a resolution soon. Thanks!

Appreciate the quick response @burnagielk

Unfortunately I did try to reinstall from the repository as well as FTP to the server before I made this thread; neither method worked on my server.

Can you provide any additional information on what our host should be looking for re: the opcache settings? If I simply ask them to “check the settings”, I’m afraid their support reps may not know what to do with that information.

Cheers!

Hi @2f4u

I’m going to mark this as “resolved” since I haven’t heard back in 2 months. I hope things are working well for you, but please feel free to make another post if you have any other issues!

Hi @brasofilo

Sorry for the confusion. That option is not a universal/global setting, but access to the / endpoint itself. If you only select “Rest API Root”, you can ONLY see that endpoint. If you select everything else BUT that, you cannot access / directly but yes, can access all of the specific endpoints that you whitelisted.

If you have a suggestion on how to make that more clear to a new user of the plugin, I’m happy to consider some ideas ?? Thanks for using the plugin!

Hi again @2f4u

So, I did some testing this evening and I unfortunately cannot replicate your issue. I hope that if I explain the steps I went through, perhaps you can indicate somewhere I went off base. Apologies in advance for the wall of text.

I first went to the wp.org repository and downloaded the first plugin you had mentioned when starting this conversation https://www.ads-software.com/plugins/jwt-authentication-for-wp-rest-api/ I’m running everything on my own machine using Local by WPEngine

Per their documentation, I first added this to my .htaccess file

RewriteEngine On
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule ^(.*) - [E=HTTP_AUTHORIZATION:%1]

Then I added these to my wp-config.php file

define('JWT_AUTH_SECRET_KEY', '12345');
define('JWT_AUTH_CORS_ENABLE', true);

I created a quick REST endpoint which simply replies with “Hello World”, which on my test site lives at /wp-json/binarytemplar/v1/test. I then went into the Disable REST API settings and ensured that Unauthenticated users do NOT have permission to this endpoint but Contributors do. Testing in a browser, I was able to confirm that these settings were working as expected for both user roles.

I then fired up Postman to test some remote posts to the JWT endpoints. First I created one which does a POST to the /wp-json/jwt-auth/v1/token route with my contributor’s username/password. This is my response

{
    "token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwczpcL1wvZGlzYWJsZS1yZXN0LWFwaS5sb2NhbCIsImlhdCI6MTYzNDYwNjEwMCwibmJmIjoxNjM0NjA2MTAwLCJleHAiOjE2MzUyMTA5MDAsImRhdGEiOnsidXNlciI6eyJpZCI6IjIifX19.0_Kmhh0YmS6pwqFSvxdjyi9WTZyeRpxk3O6lKDZinsQ",
    "user_email": "[email protected]",
    "user_nicename": "cont",
    "user_display_name": "cont"
}

Using that token, I created a second test in Postman which does a GET to /wp-json/binarytemplar/v1/test but passes the extra header as specified. With this token passed in the headers, I get a correct response and see Hello World reply from the route.
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwczpcL1wvZGlzYWJsZS1yZXN0LWFwaS5sb2NhbCIsImlhdCI6MTYzNDYwNjEwMCwibmJmIjoxNjM0NjA2MTAwLCJleHAiOjE2MzUyMTA5MDAsImRhdGEiOnsidXNlciI6eyJpZCI6IjIifX19.0_Kmhh0YmS6pwqFSvxdjyi9WTZyeRpxk3O6lKDZinsQ

If I do NOT pass this token (eg: attempt to access as an Unauthenticated user) I get the DRA blocking error which is expected

{
    "code": "rest_cannot_access",
    "message": "DRA: Only authenticated users can access the REST API.",
    "data": {
        "status": 401
    }
}

Can you confirm if any of this doesn’t line up with what you are doing on your end? Are you able to see any more details about the 401 you are getting in response?

Cheers!

I have some theories but don’t have a concrete answer, no. I won’t have the ability to look into things this weekend likely, but will definitely circle back and try to do some testing myself to see what I can dig up. Thanks for your patience!

Gotta ask the obvious questions first, always, right? ?? Thanks for understanding.

It’s odd, because no we don’t do anything to CORS at all. All of the primary logic happens at the rest_authentication_errors hook, so nothing is happening that should affect CORS based on my understanding of the permissions needed to update in order to add CORS support to REST requests. Any example I can find online about enabling CORS for the REST API seems to be mucking with the rest_pre_serve_request filter.

The logic in this plugin simply checks your allow/deny lists and pattern matches based on the name of the endpoint requested. If the user is allowed to view it based on their user role, we pass through the permissions – meaning we only get in the way of the request if the DRA settings say to block the request. Otherwise requests should be allowed to follow their “default behavior” as if DRA wasn’t even installed, whatever “default behavior” means for the endpoint in question.

As I said before, I’m still happy to look into a patch if there is anything I can do which is causing some kind of conflict, but at this point I’m not seeing what DRA could be doing to be the cause of your issue.