Return-Path: 
 <dev-return-67890-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 46449 invoked from network); 15 Nov 2004 10:56:21 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur-2.apache.org with SMTP; 15 Nov 2004 10:56:21 -0000
Received: (qmail 8216 invoked by uid 500); 15 Nov 2004 10:56:18 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 7706 invoked by uid 500); 15 Nov 2004 10:56:16 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 7693 invoked by uid 99); 15 Nov 2004 10:56:16 -0000
X-ASF-Spam-Status: No, hits=0.4 required=10.0
	tests=RISK_FREE
X-Spam-Check-By: apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Received: from [84.96.21.10] (HELO mail.anyware-tech.com) (84.96.21.10)
  by apache.org (qpsmtpd/0.28) with ESMTP; Mon, 15 Nov 2004 02:56:14 -0800
Received: from [10.0.0.27] (unknown [10.0.0.27])
	by mail.anyware-tech.com (Postfix) with ESMTP id DBCAC5EBD4
	for <dev@cocoon.apache.org>; Mon, 15 Nov 2004 11:56:12 +0100 (CET)
Message-ID: <41988B4B.1060303@apache.org>
Date: Mon, 15 Nov 2004 11:56:11 +0100
From: Sylvain Wallez <sylvain@apache.org>
Organization: Anyware Technologies
User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Attribute Rendering and CForms Convertors
References: <5E091A68F794974CAF431CA31F5AF2CC11E99F@server.bizzdesign.nl>
	 <4187D02F.9090209@nada.kth.se>
	 <1099429830.2632.49.camel@localhost.localdomain>
	 <418943A3.4080502@nada.kth.se>
	 <1099525077.2633.99.camel@localhost.localdomain>
	 <418AB060.1070901@nada.kth.se>
	 <1099698295.5116.60.camel@localhost.localdomain>
	 <418CEA15.2000609@nada.kth.se>
	 <1099886199.2688.16.camel@localhost.localdomain>
	 <418F4130.2040806@nada.kth.se>
 <1100134452.2643.30.camel@localhost.localdomain>
 <41987873.2080709@apache.org> <41988629.3000708@nada.kth.se>
In-Reply-To: <41988629.3000708@nada.kth.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

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 }