cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonas Ekstedt <ekst...@ibg.uu.se>
Subject Re: [RT] Attribute Rendering and CForms Convertors
Date Thu, 11 Nov 2004 00:54:11 GMT
On Mon, 2004-11-08 at 10:49 +0100, Daniel Fagerstrom wrote:
> We use bugzilla for new ideas and project planning also, not only as a 
> bug db. Prefix the subject line with [Patch] and mark your patch as an 
> enhancement. Of course you can new ideas and half finished stuff there 
> as long as you describe what it is. It would be very bad if we didn't 
> have a structured way for non committers to contribute ideas.

I filed an enhancement bug as you suggested.

> >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 the other hand, as has been
> >pointed out previously collecting widgets in a something like a
> >WidgetPopulator won't work unless you use flow.
> >
> >  
> >
> Why wouldn't it, can you give a pointer.

There are two stages in the life of the WidgetPopulator. During the
first request it is used to register which widgets were rendered. Then
in the second request, when the form is submitted, the same
WidgetPopulator instance is used to determine which widgets should be
populated.

I don't really know how to do this unless flow is used as you must use
the same WidgetPopulator instance in two subsequent requests. One
alternative would be to store it in the Session but then there would be
problems if two instances of the form is run at the same time.

// Jonas


Mime
View raw message