Jonas Ekstedt wrote:
On Mon, 2004-11-15 at 11:34 +0100, Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Jonas Ekstedt wrote:<snip/>
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.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.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.
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.
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 }
