Transient attributes and access rights -be careful — Mendix and Me
I recently stumbled across something that at first seems strange, but when having a detailed look is perfectly logical. If it is not noticed, it can lead to very annoying errors whose reasons are very difficult to find. Admittedly, this is not a problem that occurs very often. But the better it is perhaps to have read about it before.
What happened?
In principle, this was a standard process. Clicking on a button triggers a microflow. This microflow creates an object and initializes the attributes with values. This object, which has not yet been saved, is now transferred to a page on which the user can change or set certain attributes. Afterwards the user presses a button again which triggers a microflow in which the object is stored in the database.
So far, so standard. However, unexpected errors occurred. A closer look in the debugger showed that a particular attribute was initialized in the first microflow, but in the second microflow it had the default value from the domain model again. There was no place in the system where this attribute was changed or overwritten. Also the user had no possibility to see or change the attribute on the page. So where does the rollback come from?
Security and the Stateless Server
To understand what happened, you need to be familiar with the concept of Stateless Server (which was introduced with Mendix 7). In a nutshell, it means that the server does not save the state of objects at the end of a microflow cascade executed by the user. The current state of the objects used resides in the client (The user’s browser) and are transferred to the server with each new user interaction. The server then works with the state that was transferred by the client. This has advantages especially in the area of horizontal scalability which I don’t want to go into detail here.
By saving the current status in the client, the access rights play a major role. Only what the user is allowed to see can be stored in the client. If a user does not have read access to an attribute, the attribute is not transferred to the client. However, since the stateless server does not save the status, for security reasons it is also not transferred to the client, it is lost.
In the above example, this is exactly what happened. The user did not have read access to the attribute. However, the attribute had to be initialized for further processing. This did not work due to the client-server interaction.
An example
Let’s look at this very simple domain model
The Access Rights are defined as follows
As you can see, the user has no access to the HiddenAttribute.
Now we create an object in a microflow and initialize it with values. The HiddenAttribute is created with the string ‘Initialized’. Without committing, we now pass the created object to a page.
As you can see, this microflow writes the values of the attributes into the log. If you now execute a microflow on the page which again writes the values to the log, you can see the differences. The result is that in the create microflow the initialized value is written into the log. In the microflow which is called from the page the attribute is uninitialized again. So the information is lost.
In comparison we now consider this microflow
Here the object is committed during creation. Now the system behaves differently. The initialized value is also found in the microflow that is executed from the page. To consider this as a “solution” is a bit too short. You may not want to commit the object at this point. If you do, you may need a proper rollback strategy (if the user clicks Cancel). It also raises new questions. For example, what about an object that is committed and then changed? Let’s consider this microflow
In this microflow, the object is created, initialized and committed. Then it is modified once with page refresh and once without page refresh. The result is the expected one. All changes that take place after the commit are lost.
Conclusion
Problems of this kind do not occur very often. Nevertheless, it is useful to be aware that this behaviour exists. There is no real “solution” to the problem. It all depends on what the specific use case is. In some cases it may make sense to simply give the user read permission. If this is not possible the object has to be committed or the value has to be initialized afterwards.
I hope to have helped one or the other. Have fun trying it out. As always, I look forward to feedback.
Read more
Originally published in german language at https://mendixandme.de on December 1, 2021.
From the Publisher -
If you enjoyed this article you can find more like it at our Medium page. For great videos and live sessions, you can go to MxLive or our community Youtube page.
For the makers looking to get started, you can sign up for a free account, and get instant access to learning with our Academy.
Interested in getting more involved with our community? You can join us in our Slack community channel or for those who want to be more involved, look into joining one of our Meet ups.
