Thanks I can look at that – by the way does that endpoint expose any user names?
Here’s an example of what an app might send to this particular endpoint:
curl "https://somedomain.com/wp-json/simple-jwt-login/v1/users" \
-X POST \
-H 'Accept: application/json' \
-H 'Content-Type: application/json' \
-d '{"email":"stop.user@enumeration.com","password":"test!321","display_name":"Test"}'
And it’s response:
{
"success" : true,
"id" : "41",
"message" : "User was successfully created.",
"roles" : [
"subscriber"
],
"jwt" : "{some_jwt_token}",
"user" : {
"user_registered" : "2024-06-10 16:08:20",
"user_activation_key" : "",
"user_nicename" : "stop-userenumeration-com",
"user_status" : "0",
"user_url" : "",
"user_email" : "stop.user@enumeration.com",
"display_name" : "Test",
"ID" : "41",
"user_login" : "stop.user@enumeration.com"
}
}
For now, I suggest turning off the REST route setting in the plugin settings. Obviously, that exposes the default route.
I will log a development issue to enhance the settings so that it can be ‘aggressive,’ i.e., any route with a user (as it is now for backward compatibility) or just the WP route (or none).
Thanks for your fast replies! I appreciate it!
We’ve already suggested to our client to turn off that particular setting for now. He is reluctant to do so as that defeats the purpose of the plugin in a sense 😬
Will keep an eye out for your update.
Thanks!
Version 1.6 has been released – I have decided to code in the exception so no need to change settings.
I also added filters for the match and eexcption rule so that if other plugins conflict people can add filters to change the rules ( noted in readme FAQs now )