In Mendix, ensuring that data is properly validated is critical for maintaining both application security and data integrity. This article explores common pitfalls in entity validation and presents three robust methods for securing your application.

There are many topics around Mendix security. This article focuses on the importance of validating your entities. We look at a simple case here, although in real-world applications these scenarios are often more complex.

Let us say we have an entity called Animal, and we want only objects with a name starting with a capital “L” to be entered. We let Mendix generate the overview pages. If we run this, there is no validation at all. So we add a validation microflow. When we try to add an animal whose name does not start with the letter “L”, we get a helpful error.

So we have secured our application, and we are only allowed to enter animals whose names start with the letter “L”. But is there a catch? Using the Mendix client API, we can also create or edit objects. Let us try that in the console of the browser:

mx.data.create({
  entity: "Part2.Animal",
  callback: function (mxObject) {
    mxObject.set("StartWithL", "Elephant");
    mx.data.commit({
      mxobj: mxObject,
      callback: function () {
        console.log("Object committed");
      },
      error: function (error) {
        console.log("Could not commit object:", error);
      },
    });
  },
  error: function (error) {
    console.log("Could not create object:", error);
  },
});

We have created an object with an animal that does not start with an “L”. What is going on here? The User role has read and write access to the attribute, which means the user can change it using the client API. Adding validation behind a button is not sufficient for proper security. There are three methods for implementing effective validation.

1. Use before-commit validation

Add a “before commit” event handler. If we try our JavaScript again, we get an error message, so this approach works. In this simple case it works well. However, in more complex cases you may need additional context, and there could be many more checks requiring different conditions. Implementing this can become a significant effort.

2. Use a non-persistent entity

Another option is a non-persistent entity. We change the entity so that the user does not need write access to the attribute; our JavaScript client action will no longer work. We create a non-persistent copy of the entity, associated with the original. All user interactions with the Animal entity go through the non-persistent entity:

  • When creating a new object, create the non-persistent entity first.
  • When editing an object, copy the attribute values to the non-persistent entity and open it.
  • On save, validate the non-persistent entity. If valid, create or modify the actual object.

This method also works, but can be a lot of work and may have a significant impact on the application.

3. Use a custom Java before-commit check

An alternative is a Java action before the commit. The action checks whether attributes have changed that are not specified in a new attribute called “AllowedToChange”. If changes are detected in attributes not specified, the Java action returns an error. This means that all commits in Mendix should contain a list of attribute names separated by a semicolon.

The setup: an attribute “AllowedToChange” with no rights for users, a before-commit microflow which runs the Java action, and an extra Change Object action to specify which attributes are allowed to change. If we try the JavaScript again, we get an error in the browser console, and detailed logging in Mendix.

This introduces a safer and simpler method for implementing validation. The advantage is that it has the least impact on your app. The disadvantage is that it is not a standard Mendix solution: you have to specify the list of attributes manually, and the attribute names are not updated automatically if they change, so “find usages” in Studio Pro does not work for them. The Mendix project containing all the cases above can be downloaded on GitHub at StoneworxNL/Mendix-AttributeLock.

Conclusion

Proper validation in Mendix is essential for both data integrity and security. The three methods above provide different ways to achieve this, depending on the complexity of your application and the level of security required. If you have concerns about the security of your Mendix app, feel free to reach out; we can schedule a security assessment of your application.