Server-side block attribute validation

[stevehenty]

In Gravity Forms, we’d like to include some settings in our blocks which require specific capabilities. For example, we’d like to surface some settings that override certain features and behaviour of the form - settings that would usually be edited in the form settings and require the capability to edit forms. It's easy enough to control the display of the block settings in the browser but there doesn't seem to be a good way to control this securely when the content is saved. We’re looking for some guidance on the best way to approach this today and also provide a use case for a feature request in the future. The issue came up a while ago in #4063 and #9463 and I'm hoping it's a good time to bring it up again.

We've looked into the following approaches but all of them have problems. Perhaps you could give us some pointers or consider adding support for what we need to do.

1. Using post meta as the source for the attributes
For a single block, this works perfectly because the post meta registration includes a callback which can check the capabilities. Unauthorised users can still edit and save the content without affecting the post meta saved by the authorised user. However, this only works if there's only one block on the page. When the user adds a second block then both blocks share the same post meta so editing one block automatically edits the other. It would work if each block instance could access its post meta or at least have a way to prevent overwriting the values set by the other instances. However, I would imagine this approach breaks down when the editor is used in a widget and other contexts - unless there's a plan to handle meta source attributes differently in different contexts.

2. Server-side block attribute validation
Unlike post meta there is currently no built-in mechanism for validating block attributes on the server. There's probably a way to parse the content and prevent the saving but, as far as I'm aware, there's no way to return a custom validation message to inform the user of the reason why the saving failed and this will also break down when the editor is used in other contexts. Ideally, block attributes would support a validation callback - are there plans to introduce this?

3. Ping the server for a hash of the settings
When an authorised user changes a setting, or perhaps just before saving, the block could ping the server to generate a token for the settings and store it in the block attributes. When an unauthorised user saves the content the token remains unchanged. The token is then validated while rendering the block. This would probably work but it has its problems like additional requests to the server, securing the key and revoking the token.

In summary, the feature request is a mechanism for server-side block attribute validation. Any suggestions for workarounds would be appreciated.

[youknowriad]

Thanks for opening the issue, we discussed this during our weekly triage session. While we agree that these are valid-use cases, we think that these proposals don't always match properly the existing concepts in WordPress.

For example, the REST API to update post content is based on the fact that post_content is a string and that can be used by any kind of editor, not only block editors, which means it's not meant to handle block attributes validations.

You raised valid concerns to use the post-meta as attributes as well.

---

I think the best path forward for you is something close to the third proposal here. You can currently use the "lockPostSaving" and "unlockPostSaving" actions to disable saving "visually" while you validate the input of your settings/blocks https://wordpress.org/gutenberg/handbook/designers-developers/developers/data/data-core-editor/#lockpostsaving

We also have this issue #13413 to track the addition of hooks to perform validation before sending the save network request.

---

Adding a built-in mechanism for this to the framework is unclear at the moment because of all the downsides mentioned above. If you have a concrete proposal, please make sure to open an RFC proposal for it.

Thanks.

Related slack discussion https://wordpress.slack.com/archives/C02QB2JS7/p1555334955087600