Question

Changing Security of Marketplace Module

0

I'm faced with a seemingly impossible decision. An issue related to entity access security was found in a marketplace module that I use for managing users. As a remediation, we were asked to update the module to a version that includes the XPath constraint '[id = '[%CurrentUser%]']' on our specialized Account entity for a low-level module role also called User. This would be just fine were it not for some Account entity reference selectors that should bring up a list of all users of a certain App role. It gets this list of selectable objects from a microflow data source, shown below: The security update has forced Mendix to bring up an empty list, since Accounts now do not have read access to the attributes of any other Accounts except themselves. I can just as easily add in another entity access rule that remedies this, but then I'm waiting for a breaking change once I update the marketplace module. What would be the proper way to maintain security while at the same time keep my app functional? So far, my only idea is to have 2 reference selectors. Both would have a condition for visibility based on the footage type. Each reference selector would then have a different xpath constraint, one for lieutenants and the other for approvers. This seems like a messy approach. I would prefer to keep all the logic inside of the microflow if I can.

asked 2024-09-06

Tyler Dean

1 answers

Tim van Steenbergen · Accepted Answer · 2024-09-07

You run into this trouble-area because you are looking for two separate lists of persons but you are retrieving these from an Account entity which should only hold user-account information, but also holds person-information. Account entity has access-rules that are meant to keep useraccounts secure. Users are not allowed to see account-information. But in this microflow you want to see the person-information, stored in the same entity. So, there is no option to solve this using associations or access-rules.

My advice is to modify your domain model. Split your person-information from System.User or any specialization thereof. And if you want to store any Lieutent-specific information or Approver-specific information, they will need their own entity too, each associated to the Person entity. This will give you a more explicit and correct data-model, which always helps apps to stay maintainable.

If you choose not to do that, then there is the OQL-option. This will totally bypass any access-rule. Just download and install module OQL and copy-paste the java-action "ExecuteOQLStatement" twice to this microflow. Careful though: OQL gets you copies of the account-objects, not the actual objects themselves. With some unexpected behavior when changing and commiting the retrieved objects. But it might help you out for this microflow.

Best of luck!