Hello Ahmad,
Are you running locally, or on a sandbox environment? In that case, users won't be blocked. Blocking users is done based on the DTAPMode of your app. When this is set to Production, users will be blocked. When it's not set to Production, users will not be blocked. When running locally, or on a sandbox environment, the DTAPMode is set to Development, and users won't get blocked.
When you deploy to a licensed node on the Mendix Cloud, the DTAPMode will always be set to Production and the users will always get blocked after the maximum number of failed attempts.
I just did a test with Mendix 8.5 on a licensed node and users are getting blocked after the maximum number of failed attempts.
WARNING Core: Login FAILED: invalid password for user 'MxAdmin' (1 failed logins).
WARNING Core: Login FAILED: invalid password for user 'MxAdmin' (2 failed login).
WARNING Core: Login FAILED: invalid password for user 'MxAdmin', user failed to login for 3 times and therefore is blocked now for approximately 5 minutes.
WARNING Core: Login FAILED: user 'MxAdmin' is blocked.
Hi Ahmad,
Did not verify in the modeler, but this is what the decumentation has to say: https://docs.mendix.com/refguide/login-behavior
1 Default Login Behavior
A user is blocked after 3 consecutive bad login attempts, regardless of the time between the login attempts. The failed login count is reset after a successful login attempt or when a blocked user is unblocked.
Users are unblocked each time the cluster manager runs, and at that point, the failed login count is also reset to 0. By default, the cluster manager runs every 5 minutes. This interval can be changed using the Runtime customization ClusterManagerActionInterval setting.
The cluster manager does more than just unblocking users. For example, it also removes expired sessions. So, changing this interval has a broader impact.
If a user is blocked just 1 second before the cluster manager starts to unblock all blocked users, the lock is removed after 1 second.
2 Customizing Login Behavior
Login behavior can be customized by implementing a custom Java action and registering it to be used instead of the default login action.
Cluster manager behavior currently cannot be changed.