For the Simplified Chinese translation, click 中文译文.
Security in Mendix has two sides: you want different people to see different parts of your application and you want to prevent unauthorized access. Both of these can be managed from Studio Pro. Access to forms, data and microflows can be limited to authorized users.
Security in Mendix does not include scanning files that end-users upload or download from your application for viruses and malware. For more information, see the Scanning Uploaded Files for Malicious Content section in How to Implement Best Practices for App Security.
2 Security Levels
If you want full security, you need to explicitly give access to forms, entities and microflows before someone can access them. By default, no one can access anything. To make it easier to create prototypes and demos there are security levels that require less security settings than are needed for a production system.
See Project Security for a description of the security levels.
3 Project vs. Module Security
At the level of a project some global settings can be specified: the security level, the administrator account and whether or not to allow anonymous access.
See Project Security.
Most of the security settings take place at the module level. This has the advantage that a module can specify its own security and can be distributed and reused in other projects. Access to forms, entities, microflows and datasets can be configured.
See Module Security.
4 User Roles vs. Module Roles
An end-user in a Mendix application has one or more user roles. These roles can be assigned from within the client when creating or editing a user. User roles are at the level of a project and can be edited in Project Security.
See User Roles.
Each module defines its own set of module roles and you only have to specify security within a module in terms of those module roles. An e-mail module maybe has two module roles, one for normal user and one for an administrator; other modules may have just one or more than two module roles depending on the requirements for those modules.
See Module Role.
A user role is a combination of module roles. A user that signs into the system gets the access rights of all of his or her user roles and indirectly to the module roles that are contained by those user roles.
Let us say you have a project with two modules: System and ProjectManagement (PM). The PM module has three module roles: TeamMember, TeamLeader and Administrator. And let us say that in this case, we only need two user roles because we do not need the distinction between team leaders and administrators. You define those two user roles and assign module roles to them. The table below shows which module roles are contained within the user roles. Note that you always need at least the User role in System.
|User Role ‘TeamMember’||User Role ‘TeamLeader’|
5 Entity Access vs. Page Access
Per entity you can specify who can read or write what members (attributes and associations) under what circumstances. Using XPath constraints you can express powerful security behavior; for example, “an employee can only see orders created by the department he is a part of”.
Per page you can specify who can open it from navigation. The menu bar is optimized so that only pages that the user has access to are visible.
A combination of entity access and a page access is necessary because entities can also be accessed from microflows and custom widgets. Furthermore, you can express more advanced security through entity access.
See Entity Access.