I prefer not to install any additional plugins. Is there a filter in Pods or WordPress that I can use? If i look at the Pods source code there is a function called “field_allowed_to_extend” in the “PodsRESTFields” class but there seems to be no filter attached to that function. But maybe there is some filter to be used.
Anyway thanks for your fast response.
The plugin is open source and exhaustive. Yes it uses WordPress core filters. Every functionality will be code. Please download the plugin and search its files for “add_filter” and “add_action” or “apply_filters” to see all filters used and added.
Specifically see the on_rest_pre_dispatch function on line 248, hooked to the WP core filter rest_pre_dispatch on line 42. This is the method for modifying anything in the REST API before it responds. Everything else in the plugin is either user interface for settings or optional authentication by JWT.
Thanks, I will look into that filter. It would be great if it was an additional option like “Restrict read access to logged in users” under the REST API field setting. Maybe something for a future update of Pods 🙂
Don’t mind me, just added the ability to require logged in users for reading fields as a new option in Pods 3.2.2 🙂
Should be out this week.
Wow, that’s sounds perfect! This will increase security and prevent web scraping. Even better would be if you could “Restrict rest access by Capability” on a field by field basis.
Thanks!
-
This reply was modified 1 month, 3 weeks ago by
bluelumines.
Capability checks are being worked on.
Additional settings for that require a more complex user interface, as capabilities extend to both read and write operations over REST.
This can be seen on the commit for adding the checkbox and the commit for hiding additional options until capabilties cover all possible use cases.
Until then, WordPress core REST filters like rest_pre_dispatch provide information about the nature of the request, and is_user_logged_in() and current_user_can() can be used to check capabilities before returning a response.
The linked documentation for rest_pre_dispatch links further to documentation on the WP_REST_Server and WP_REST_Request classes which are passed to the filter.
The methods of these objects provide all the information about the nature of the request. The first contains information about all endpoints and namespaces. The second has methods for getting information about the specific matched request.
Based on that information, a function attached to rest_pre_dispatch can return an WP_Error or exit if desired conditions are not met.
What if Pods just followed the same Visibility options in the Field option for the REST API value with another toggle option in the REST API section defaulting to on just below the Read access checkbox. “Require all enabled Advanced > Visibility field options to read this field value via REST” or something like that?
Sounds like a good idea. To always publicly expose all fields if the REST API is enabled and “Show All Fields” is checked may have some security concerns is some projects. So a mechanism to control this like the last update is great.
A way to set field visibility based on user capabillity would be great.
In in the REST API tab it would be great if you can set the same capability for all fields and for even more fine control it would be nice if you could set capability on a field by field basis. For example if some fields hold more sensitive or personal data the user need higher capabilities.
Thanks
By the way the last update seems to intoduced a bug, if you enable REST API and check “Show All Fields (read-only)” the fields aren’t visibale at all.
