Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Jonas Ekstedt wrote:
<snip/>
What I meant was that in the scenario above a malicious user can add a
request parameter "bigDangerousButton" to the POST and it will be
processed by the population mechanism (firing off button events) even if
the user has role "user" in the example above. I think this would
actually be quite a common usecase having one form template rendered
differently depending on what type of user access it. The problem is
that a population mechanism without knowledge of what has been rendered
cannot make decisions about which widgets are eligible for population.
On that particular point, it seems to me *especially dangerous* to let the template decide what what widgets are to be displayed depending on user roles.
ACL is an application-level concern, and *must* be handled by the controller and/or the application logic. That's what widget states allow: by setting the "bigDangerousButton" state to invisible, you don't even need the <jx:if>. The <ft:widget id="bigDangerousButton"/> will simply render nothing if the widget's state is invisible.
I agree about that, ACL is definitelly not a view concern. It should be enforced in the business logic and supported in the form model. I think widget states is a good way to support ACL in the form model, even if I would have preferd to make it declarative rather than programatic. One way would be to let the form definition take parameters, so that choice (union) can check if e.g. an administrator parameter is true and in that case include the "bigDangerousButton" in the form model, otherwise not. In this way the the widget would not only be invisible for ordinary users, it would be non existent. And there would be no risk that faulty event handling code would make it visible in some corner case.
Just some RT, but declarative ACL could maybe be achieved through widget attributes, e.g.
<fd:field id="sensitiveInfo">
<fd:attributes>
<fd:attribute name="acl" value="boss, admin, root"/>
</fd:attributes>
</fd:field>
and then have this information be handled by some kind of on-create event listener, or some form-level aspects.
Just a RT, though...
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
