cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [RT] Attribute Rendering and CForms Convertors
Date Tue, 16 Nov 2004 08:39:42 GMT
Jonas Ekstedt wrote:

>On Mon, 2004-11-15 at 11:34 +0100, 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.
>>    
>>
>
>In my view there are three aspects to ACL. Taking the example of a form
>that can be viewed or edit:
>
>* Are we in view or edit mode (a controller concern)
>* Should I show a field widget or simple text (a view concern)
>  
>

What's the difference with the first aspect?

>* Should I set this value (a model concern)
>  
>

 From a from framework POV, this aspect should be "should I accept user 
input for this value", as the domain model shouldn't care about form 
handling.

>Ideally all the controller would have to do is:
>if (user.role == "admin")
>  cocoon.sendPage("page", {mode: "edit");
>else
>  cocoon.sendPage("page", {mode: "view");
>  
>

And what about:

if (user.role == "admin")
  form.setState("disabled"); // or "output" to show only text
else
  form.setState("active");

cocoon.sendPage("page");

>The view would do:
><jx:choose>
>  <jx:when test="{mode == 'edit'}">
>    <field name="name"/>
>  </jx:when>
>  <jx:otherwise>
>    ${name}
>  </jx:otherwise>
></jx:choose>
>  
>

And the view would do:

  <ft:widget id="name"/>

>And the model would do:
>public void setName(String name, User user) {
>  if (user.getRole().equals("admin"))
>    this.name = name;
>  else
>    throw SomeException();
>}
>  
>

Yup.

>Alternatively you could have your beans wrapped in some ACLModel that
>enforces the ACL policies.
>  
>

Yup. Or AOP-driven ACLs.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


Mime
View raw message