David E Jones wrote:
In other words, it is nice to check permissions on the client side and/or show permission impact in the UI, but that just improves the UI... it doesn't actually enforce any of those permissions checks because it is really easy to change HTML and/or spoof a request (ie users with valid credentials that can do other things could then get around permissions that are only checked in the UI).
I think Jacopo's interest is an improved UI. Why render a Create New button when the user doesn't have the permission to create anything?
The trick is how do we setup permissions so that we set them up once and they function in both places (ie in the input processing for the actual security, and in the UI for user convenience)?
Is that even possible? The UI might contain multiple paths to follow, with each path requiring a different permission. Service invocations are generally a single path with a single permission.
In other words, the UI might need to know the user's create, update, and delete permissions in order to render the screen, but the user action will result in only one service invocation - which requires only one of those user permissions.
I thought about this a while back, and toyed with the idea of making the screen widgets permissions-aware.
-Adrian
