cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [C2]Access control using sitemap
Date Sun, 10 Sep 2000 07:41:01 GMT
At 04:15  9/9/00 +0200, you wrote:
>  <match type="uri" pattern="myapp/**">
>    <!-- the following Matcher make the overall request
>         analysis and makes important information available
>         to subsequent components through the objectModel and
>         a Map for substitution in src= attributes.
>         Maybe a Controller sitemap component would be more 
>         appropriate
>    -->
>    <match type="myapp-controller" pattern="not really used">
>      <select type="myapp-action-selector">
>        <when test="add">
>          <!-- here the {1} is delivered by the matcher
>               "myapp-controller"
>          -->
>          <generate src="myapp/{1}/add.xsp"/>
>        </when>
>        <when test="remove">
>          <generate src="myapp/{1}/remove.xsp"/>
>        </when>
>        <otherwise>
>          <generate src="myapp/{1}/index.xml"/>
>        </otehrwise>
>      </select>
>      <select type="browser">
>        <when test="netscape">
>          <transform src="myapp/{1}/style-ns.xsl"/>
>          <serialize type="html"/>
>        </when>
>        <when test="wap">
>          <transform src="myapp/{1}/style-wap.xsl"/>
>          <serialize type="wap"/>
>        </when>
>        <otherwise>
>          <transform src="myapp/{1}/style-ie.xsl"/>
>          <serialize type="html"/>
>        </otherwise>
>      </select>
>    </match>
>  </match>
>  <-- here we catch all requests not handled by the match above
>      and redirect them to the login screen or an error page
>  -->
>  <match pattern="myapp/**">
>    <redirect-to uri="myapp/login"/>
>  </match>
>Well, this example might not be the best one but I think its
>good enough to start a discussion about it. What do you think?

I like the approach but before an implementation can be defined there is a
few questions that must be answered first. Namely

* What is an Action ?
* How will you use actions ?

What is an Action ?

In the above case you have associated an Action with a resource. ie the
Remove action is associated with myapp/{1}/remove.xsp resource. Do actions
have to be associated with a resource or are they independent of resources.
I would say that they are independent - an Action framework should be able
to be used via multiple interfaces whether via cocoon, turbine, telnet,
mail etc. So the "ShutdownRealWorldMachine" action is accessible via the C2
interface, a telnet interface or via any number of other methods.

An action is essentially a snippet of code that is executed in response to
a request in a certain context (or Environment in C2s case). The action can
add and change the context/environment data.

How granular can actions be ? Does session validation count as an action ?
How about authorisation and authentication ? What about form validation ?
When I program actions I use a extremely granular approach.

There is also the idea of latent actions. For instance the latent Action is
transmitted between end-user and cocoon until they are activated. Actions
may also be made latent (or deactivated) in a couple of cases. Like when
you try to submit form but are not logged in - it will save action/form
data (or put action into latent state) and then after login commit the
action (or re-activate action).

How will you use actions ?

In many cases when I program to a an actions approach each request can
result in many actions being executed. For instance it is not uncommon for
an action chain to occur like the following.

SessionValidatorAction --> RoleAssignerAction --> FormValidationAction -->

The SessionValidatorAction will check the session and if not exist then it
will put a magic token in environment so that after action is executed then
the rest of action-chain and output resource is ignored and the user is
redirected to a login page.

The RoleAssignerAction (lame name I know ;->) will check if the current
user implements a certain role and if not redirect them to appropriate
NoEntry.html type page.

So when I designe a sitemap for a web-application I want to somehow be able
to do the following.

* Anything under webapp/ must run SessionValidatorAction
* Anything under webapp/admin must run RoleAssignerAction and check for
"admin" role
* Then specific resources webapp/a.xml, webapp/b.xml and webapp/admin/c.xml
must run FormValidationAction with appropriate form schema and the
apprporiate FormDBEntryAction
* A user can also arbitarily submit an action from any page (via post
request or perhaps a ?action=blah tacked onto URL) that must be executed.


So what would I want to see in a Cocoon-Application framework ???

Well actions are independent of resources and exist in a seperate namespace. 

Each request can in theory result in a action-pipeline.

Each action can add stuff to it's context (or Environment).

Each action can in theory short-cut the action pipeline and move to another
action-resource pipeline and also store remaining submitted actions as
latent actions.

An action pipeline must not necessarily be associated with a resource (it
should instead be able to specify a resource that it goes to post processing).

It may also be good to have an action that's sole purpose is to extract
explicit action requests and execute/store them (ActionExtractorAction +
ActionDispatcherAction ???)

But anyways I mean in no way to imply C2 is bad and if you want to add
hooks into sitemap generation to allow for this sort of stuff (or even
better do it yourself ;>) I would gladly switch all my development across
to C2 and I suspect many others would too :P.

Anyway I should stop ruffling feathers considering I don't plan to
implement this for quite a few months :P



| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power."          |
|       -Abraham Lincoln                               |

View raw message