I don't know if there is somewhere else for this...
https://learn.outsystems.com/training/journeys/web-developer-exam-2993/best-practices-for-building-screens/odc/6729
There's explicit instruction elsewhere in the training NOT to use Check###Role() on the enabled button, but to only use it on the visible property, because you can just hit F12 and enable the button.
Use Check<Role>() only for the Visible property, not for Enabled.
Final Answer:
If you use Check<Role>() in Enabled, users can bypass it via browser dev tools (F12) → security risk
Always control access at Visible level + server-side validation
Buttons should be hidden (Visible = Check()), not just disabled
Correct practice:
Visible = CheckManagerRole()
Enabled = True
Wrong practice:
Enabled = CheckManagerRole()
Conclusion:
There is no real conflict — training that suggests using it in Enabled is misleading.
Follow best practice: use roles for visibility, not just enable/disable.
Correct, Check_role() for Visible
Hi All,
Notice that it doesn't say OR but AND, so it doesn't say you should ONLY use enabled property.
But this is all moot in the context of security best practices, I'm not saying you shouldn't do it, but it is in no way secure.
Any measures you take client side can fairly easily be broken, these measures are only a matter of how easy you make it for the complete novice "let's see what these dev tools are all about" sunday hacker.
Because anyony with a couple of hours and patience (or nowadays, help from Claude) can make any button with either combination of visible and disabled on an OutSystems ODC/Reactive application, function anyway.
I'd say, treat the client-side checkrole as a way to make the UI more fitting with the role the user has, hiding and/or disabling stuff as to not clutter his UI and confuse him with things he can't use anyway, but don't see it as security.
Dorine
Hi Dorine,
Thanks for your reply.
"Notice that it doesn't say OR but AND, so it doesn't say you should ONLY use enabled property" - I agree that it is technically correct, the best KIND of correct, but I think it's not clear enough that you MUST set the visible property.
Also, if you set the Visible property, setting enables in pointless, since they can't see it anyway. If leaves it open for someone to just go "OK I'll set the Enabled property".
It just gives the impression that you can use either... it shouldn't mention the Enabled option at all in this context, since using Enabled to apply security logic breaches the OutSystems security guidelines.
Kind Regards
Nathan
Also, if you set the Visible property, setting enables in pointless, since they can't see it anyway. Yes, i have to fully agree on this one, setting the enabled with the exact same conditions as the visible is pretty pointless.
But i remain with this : both visible and enabled are more about UX/UI than about security, i.e. neither is secure at all.
Usually (almost always), you don't want somebody to see elements like links and buttons he has no business executing, sometimes though for purpose of consistency or screen design or showing context, i like to leave a certain element in, disabled.
I have been searching a bit for this, can't quickly find it, do you happen to know in what course : There's explicit instruction elsewhere in the training NOT to use Check###Role() on the enabled button, but to only use it on the visible property, because you can just hit F12 and enable the button
"i like to leave a certain element in, disabled" - and I'll just hit F12 and enable it...
"do you happen to know in what course" - I'd have to go through and search all the course material... I think it's in the videos.
They basically say you should only use it on the visible property, and that you should check the role at the very start of the action the button calls, because if someone has access to the screen, they have access to ALL the actions on the screen, regardless of what calls them.
Kind Regards,
"They basically say you should only use it on the visible property, and that you should check the role at the very start of the action the button calls, because if someone has access to the screen, they have access to ALL the actions on the screen, regardless of what calls them."
Hi!So, a few things.Traditional Web Applications.For Traditional Web Applications, the recommendation to have the CheckROLENAMERole() check on Visible (and not on Enabled) makes sense because the HTML is built server side. If the element is not visible, it will not be in the HTML sent to the Browser. But it's actually useless. A colleague was able to execute the Screen Action attached to the button (that was not in the HTML at the browser), in 5 minutes.But the recommendation to check roles (and anything else you need to validate the request) at the start of the Screen Action makes sense here. In Traditional Web Applications, they are executed server-side.O11/ODCFor O11/ODC, the screen is built client-side and the screen actions are executed client-side.So, hiding elements (like buttons) or checking roles inside the screen actions is absolutely useless in terms of security.Also, I think the CheckROLENAMERole is only available client-side in ODC. In O11 you have to create a client action and use JavaScript to check the user role in screens.This means that in O11/ODC, everything you do regarding showing/hiding things is related to improve the user experience.Now, one thing that we have here that isn't available in Traditional is the following.When You define ROLES at the screen Roles section, you are saying which roles can access the screen.Will this prevent someone without the role of being able to access the screen?Nope. They can mess with the JavaScript code that creates the screen and bypass this.BUT...The application will generate logic to check automatically EVERY request to the server, from a screen, to check if the logged user has the roles defined on the screen. It will check for Aggregates at the screen, for Data Actions, for Server Actions called from the screen.If your screen has only one role defined, you are almost safe. As Aggregates and Data Actions endpoints will be called only from that screen, they are protected. But server actions can be called from different screens, with different roles. So things are more complicated.The best practice in this case is:If your screen has only ONE role, Server Actions should still check the required role at start before doing anything else.If your screen has MULTIPLE roles, ALL server-side elements should check the appropriate roles (including aggregates and data actions).Again, security only exists server-side.So, when they say:"Control the access to the screen's widgets, such as buttons or links, using the Visible and Enabled properties. Use the CheckROLENAMERole() function to validate access only to authorized roles." It gives the impression you are making a "security setup", but you are not. This is User Experience.Cheers.
I use the following approach:If the user can't execute the action related to the button because he has no permissions, I hide it. If the user can execute the action (they have permissions), but it depends on other conditions related to the data itself, I prefer to disable the element. This makes easy to the user to know he CAN do that but not right now (missing data, ranges, etc), and makes it easier to design the screen (without having to worry about buttons moving, etc)Of course, if it is up to me :)It's not always the case...
Hi Eduardo,
Yes, exactly. I was using Trad Web as the example... yes of course, with O11/ODC/Mobile you have to validate all security rights and data on the server side actions, as well as the client actions. (Client side first prevents unnecessary server visits.)
Maybe the best-practices-for-building-screens document could be updated to reflect what everyone has discussed, especially your "If the user can't execute the action related to the button because he has no permissions, I hide it. If the user can execute the action (they have permissions), but it depends on other conditions related to the data itself, I prefer to disable the element. This makes easy to the user to know he CAN do that but not right now (missing data, ranges, etc)" - this seems like the best practice.