Limit properties send by the wire (frontend <-> backend)

[wojtek-krysiak]

Describe the problem feature solves Right now an entire record is sent between frontend and the backend. In between, there is a conversion to string (required by FormData) which may alter the data which are not shown.

Example cases where this is wrong

1. we have a model with secret property: 'superSecretProperty' and even if we market this as inVisible it can be intercepted in the Network tab.
2. there is a field, sat by some logic: 'developmentState' which is null and it shouldn't be editable. But when we open this record it is fetched from the backend, then goes to the state, and finally when user hits save -> goes to the backend (and it is converted to empty string in the process) and is saved there to the database as ""

Describe the solution you'd like

1. • When user limits payload to some restricted array - other properties should be stripped from it.
2. Another option would be to write a feature which will do that

Acceptance criteria

• [ ] add new Action#permitPayload property which will be Array (array of permitted paths)
• [ ] when an action has Action#permitPayload set- only values from this array should be permitted in the payload.
• [ ] all Action#permitPayload should check also for all nested properties so if Action#permitPayload = ['nested'] it should allow: 'nested', 'nested.1' etc

permitPayload can be changed to some other name, but not permit, since it is related to access controll

[KrishnaPG]

One way this is implemented in frameworks such as Meteor is to have a separate client side resource equivalents.

This is similar to "views" in the database terminology, where a subset of columns are extracted and treated as a different table that has (usually) readonly access.

In the present case, separate client side resources are to be created that have subset of the properties of their "server side resources". Client can access only the "client side resource" portion of the full resource. The client side and server side resource objects are always kept in sync (automatically).

User can continue to "show", "hide" properties on the client side resource, just as they would currently. Only that few properties are never accessible to them. For example, computed properties, such as hash of the object, or modified at etc. they are retained in the server side, while the rest of the properties are made accessible to the client side.

When edits are committed on the client side resource, it will sync the changes to the server side object, where the remaining properties are filled (i.e. hash is calculated, modified at dates are populated etc.) based on the user supplied code.