Best practice needed: Prohibit access to DS fields from users depending on logon name

[Blama]

Hello Isomorphic,

could you please point me to the right location for this use case?

I have an application with many users from different entities. Some may see all fields of a DataSource, some may only see specific fields.
I know about the viewRequires-attribute, but this might not be enough as the Admin of the application can configure who may see what.
Of course, on the client I can decide to show or not to show some fields depending on the application settings. But I also want the data not to be transferred to the client in the first place.

So in my imagination I'm looking for something like

1. .ds.xml-file with all possible fields and their default-configuration with a serverConstructor set to a SQLDataSource subclass I write.
2. In that class some DSRequests to get my application configuration and some if-statements remove fields / set field-properties depending on the current user I get from the session and the result of the settings-DSRequests.
3. On the Client, the DataSource-definitions returned by sc/DataSourceLoader will or will not have the fields depending on the configuration.
4. Fetches from the client will never include hidden data, as the DS is recreated on the server for every client request.
5. Updates from the client will never be able to write to hidden fields as the DS is recreated on the server and does not include the fields hidden for that user, so the server will ignore that data (if the user manages to sneak in data for a field he or she can't see).

Another use-case would be to set required="true"/"false" on the server depending on the application settings and logged-in user. Here I could do the same with a serverside custom validator, but that would be serverside.

I'm pretty sure that these "dynamic DS" are already possible and straight forward to use, but I did not find the right documentation / sample, yet. Is it somehow related to Interface DynamicDSGenerator?

Thank you & Best regards,
Blama

[Blama]

Hello Isomorphic,

I looked further and am a bit stuck. I'm pretty sure that this is done with DynamicDSGenerator. But do I really have to manipulate the XML like in this thread?

I think so, because for example the serverside DataSource class has nothing related to addField / removeField and the serverside DSField class has no setters.

Best regards,
Blama

[Isomorphic]

If you actually need a DynamicDSGenerator, yes, you manipulate the XML definition of the DataSource. This is partly because it makes it easy to retain a declarative approach for all DataSource features that don't require dynamic generation, and partly because once a DataSource is defined its definition is permanent. A series of addField() APIs and similar setters would leave a lot of ambiguity about lifecycle (when it is legal to make such calls vs not).

However, we see no immediate reason why you need a DynamicDSGenerator. You seem to be aware of the viewRequires attribute, but then you go on to say that you think it doesn't solve your problem.

I know about the viewRequires-attribute, but this might not be enough as the Admin of the application can configure who may see what.
Of course, on the client I can decide to show or not to show some fields depending on the application settings. But I also want the data not to be transferred to the client in the first place.

However nothing you've noted here - dynamic changes to which users can see which fields, for example - would be a problem for the viewRequires feature, since it basically just calls arbitrary logic that you define.

[Blama]

Hi Isomorphic,

ah, viewRequires, editRequires, initRequires and updateRequires are VelocityExpressions, so I really might be able to handle it that way. I'll try.

One more question: If editRequires returns false and the field is required="true", will that work or fail?

Thank you & Best regards,
Blama

[Isomorphic]

It will do what it says it'll do: require the field to be present in order to pass validation, but not allow a DSRequest from the browser that contains a new value for the field.

This isn't a nonsense setting. With an existing record, the overall record would still be editable by users if the user was not trying to submit a value for the field, and the existing record already had a value for that field. And it would still be updateable by server-side code, which isn't subject to Declarative Security checks by default.