Jonas Ekstedt wrote:
On Mon, 2004-11-08 at 10:49 +0100, Daniel Fagerstrom wrote:
<snip/>
I don't follow you here can you give some more details for that scenario.Another way of doing the same, which I think was the agreed upon way to do it is to populate all widgets that has a request parameter present. This works out the same way with one little caveat. Some day someone is going to do
<jx:if test="${user.role == 'admin'}"> <ft:widget id="bigDangerousButton"/> </jx:if>
and will be in for a mighty surprise.
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.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
