cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonas Ekstedt <>
Subject Re: [RT] Attribute Rendering and CForms Convertors
Date Tue, 16 Nov 2004 01:03:04 GMT
On Mon, 2004-11-15 at 10:35 +0100, Sylvain Wallez wrote:
> Jonas Ekstedt wrote:
> >On Mon, 2004-11-08 at 10:49 +0100, Daniel Fagerstrom wrote:
> >  
> >
> <snip/>
> >>>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"/>
> >>></jx:if>
> >>>
> >>>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.

The problem with this approach is that normally (I would think at least)
widget states will be changed in a manner orthogonal to the widget
hierarchy. The widgets being hidden will be all over the form rather
than under one single fd:struct that can be switched on/off.

Take the current project I'm working on. I have a Taxon (4 subclasses)
which contains a list of Specifiers (3 subclasses) which contains a list
of Tokens (4 subclasses). Each of the subclasses are rendered
differently depending on class and whether they are edited or viewed.
The user can also choose whether to view/edit the whole hierarchy at
once or only parts of it.

To do this I use one jxmacro for each subclass. The macro renders form
fields if ${edit == 'true'} or text otherwise. It would be a nightmare
trying to do this with CForm as I would have to walk around the entire
widget tree setting widget states when switching between editing and

// Jonas

View raw message