cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Attribute Rendering and CForms Convertors
Date Mon, 15 Nov 2004 10:56:11 GMT
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:attribute name="acl" value="boss, admin, root"/>

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 Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message