cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonas Ekstedt <>
Subject Re: [RT] Attribute Rendering and CForms Convertors
Date Tue, 16 Nov 2004 01:29:46 GMT
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)
* Should I set this value (a model concern)

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

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

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

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

// Jonas

View raw message