It already works that way.

When you call a Server Action from Screens, a REST API gets created for each Screen the Server Action is consumed on. That API requires the user to have the same roles as the Screen does.

J.Ja

hey everyone, bit confused by this and what is shown in the  course below, the approach used there seems also rather unproductive/repetitive, does the above note by Justin note implies it's actually not needed? Still very new to sstudio but find rather strange that role configuration is not configured at server side, vs screens. even to allow reuse and avoid duplicate permission configuration, should flow server -> screens

https://www.outsystems.com/training/lesson/2032/demo-how-to-control-authorization-in-logic?LearningPathId=18

my initial reaction after seeing the video and try on sstudio was exactly like the ideia above, would be much more intuitive and solid from security perspective.

more recent one

https://www.outsystems.com/ideas/10405/server-action-role-based-security-with-checkboxes

thoughts?

ps-adding, also not sure would the described behavior would work on a screen which allows operations (calling different server actions) with different role requirements. ex screen can be accessed by role A and B, but only role B can can do a specific action ?

Hi Rui,

Thanks for your comments. I've tried to explain some best practices in How to secure your reactive and mobile apps which might clarify your questions and concerns. 

Regarding that other idea I'll merge it with this one. Making the security explicit in actions (or maybe even better, allowing a simple centralization of read/write security rules on the data itself) could be something we pursue in the future. 

Cheers,
Tiago Simões

thanks Tiago for all the notes, still going through and thinking :) lots of nuances

https://www.outsystems.com/ideas/8979/reactive-consumed-server-actions-authorized-roles/#IdeaComment30727

@Justin James 

Can you give more information about this role access control? 

For example in this situation: If you call a server action from a button click action where the button is only visible or enable for an admin, does the API check only the admin role or does it check the screens roles?

Because it seams that that feature helps in some situations but it does not give the same control for the developers as if you put a role check in the actions like it happens in the screens. If that is the case, then this idea should be open and not put has implemented.

Exactly what I said. It uses the screen's roles. Something's "hidden"? It's just client side code. Someone can change the JavaScript and un-hide it. Nothing client side is "secure".

J.Ja

https://www.outsystems.com/ideas/8979/reactive-consumed-server-actions-authorized-roles/#IdeaComment51575

@Justin Malbis 

Yes indeed. So in this case you need to include role validation on the server or service action. The built-in feature of OutSystems doesn't suit this case. And I think that @Francisco Silva was mentioning more because of this.

As a developer, it is very common to start public server or service actions with the typical CheckRole actions. For that reason, it would make sense for me to have already that logic implemented in a built-in feature for the actions, like you have on the screens. It would save us time.

That is why I was considering that this idea should not have the status "Implemented".

What do you think?

It doesn't matter what I think, I don't work for OutSystems, and regardless of what I agree with, the status won't change.

J.Ja