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 09:35:47 GMT
Jonas Ekstedt wrote:

>On Mon, 2004-11-08 at 10:49 +0100, Daniel Fagerstrom wrote:


>>>Another way of doing the same, which I think was the agreed upon way to
>>>do it is to populate all widgets that has a request parameter present.
>>>This works out the same way with one little caveat. Some day someone is
>>>going to do
>>><jx:if test="${user.role == 'admin'}">
>>> <ft:widget id="bigDangerousButton"/>
>>>and will be in for a mighty surprise.
>>I don't follow you here can you give some more details for that scenario.
>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.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message