I don't think it is common that permissions checked in the UI are
different than permissions checked when the input from the UI is
processed. In fact, I don't think I've ever run into that problem.
The problem I have run into over and over is that in almost every
toolkit and framework around (with just a few exceptions) you have to
configure or code the permission checks twice, and they often get
accidently out of sync (causing either usability problems or security
vulnerabilities).
If we're going to talk about extensions to the form widget or other
things for security purposes, I think we should talk about this
redundancy problem because it IS an issue for the framework and one
that people talk about when comparing the OFBiz framework to certain
competing modern frameworks...
-David
On Apr 30, 2009, at 4:42 PM, Adrian Crum wrote:
No, I'm not saying I disagree with you. You totally missed my point.
I don't think anyone is suggesting removing permissions checking
from the UI or the services. Let's get that settled right away.
Jacopo is asking for a way to control the display of screen widgets
based on the user's permissions. You said: "The trick is how do we
setup permissions so that we set them up once and they function in
both places?" Maybe I'm misunderstanding your question. It sounds to
me like you're suggesting a single method could be used in both
scenarios, so I responded that the requirements are different - so a
single method wouldn't work.
We're already using permissions to control the UI - and they are the
same ones used in the service calls. The problem is, it's hard to
implement. I believe all that's being suggested here is some new
widget attributes or something to make it easier.
-Adrian
David E Jones wrote:
On Apr 30, 2009, at 4:09 PM, Adrian Crum wrote:
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?
Yeah, that's what I said... ie with phrases like "that just
improves the UI" and "in the UI for user convenience".
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.
So, are you saying that you disagree with what I wrote about the
purposes of permissions in different places, ie:
1. input processing: for security
2. UI artifacts: for user convenience (improved UI)
Maybe what I wrote wasn't clear enough, so I'll say it again:
permission checking in the UI is USELESS for security, it only
helps for an improved user experience.
I would even go so far as to assert that if anyone doesn't
understand this then they don't understand how web-based
applications work, and the applications they write will be full of
security holes.
This is why in OFBiz we REQUIRE security for services (or other
input processing logic) and it is OPTIONAL in the UI.
-David
