cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
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:
>>>>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 

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

And what about:

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


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

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"))
> = name;
>  else
>    throw SomeException();


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

Yup. Or AOP-driven ACLs.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message