Return-Path: 
 <dev-return-67887-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 31625 invoked from network); 15 Nov 2004 10:34:49 -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:34:49 -0000
Received: (qmail 82640 invoked by uid 500); 15 Nov 2004 10:34:48 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 82201 invoked by uid 500); 15 Nov 2004 10:34:46 -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 82187 invoked by uid 99); 15 Nov 2004 10:34:45 -0000
X-ASF-Spam-Status: No, hits=0.4 required=10.0
	tests=RISK_FREE
X-Spam-Check-By: apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Received: from [130.237.222.202] (HELO smtp.nada.kth.se) (130.237.222.202)
  by apache.org (qpsmtpd/0.28) with ESMTP; Mon, 15 Nov 2004 02:34:42 -0800
Received: from [192.168.105.46] ([192.58.197.171])
	(authenticated bits=0)
	by smtp.nada.kth.se (8.12.10/8.12.1) with ESMTP id iAFAYMBD018540
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <dev@cocoon.apache.org>; Mon, 15 Nov 2004 11:34:27 +0100 (MET)
Message-ID: <41988629.3000708@nada.kth.se>
Date: Mon, 15 Nov 2004 11:34:17 +0100
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
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>
In-Reply-To: <41987873.2080709@apache.org>
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

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.

/Daniel