cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Royal <pro...@managingpartners.com>
Subject Re: [RT] Access Control (was [RT] Cocoon as OS)
Date Thu, 07 Feb 2002 02:54:32 GMT
On Wednesday 06 February 2002 07:06 pm, Stefano Mazzocchi wrote:
> my personal opinion is that I don't see anything that justifies the
> inclusion of AC at the sitemap level since AC is just another action.

i agree. it would make a great pluggable webapp though.

a "blocklet" if you will; some actions, transformers and maybe a custom 
protocol handler could do it all.  AC might be a great first candidate for 
hammering out a component app API. (which could maybe be applied via 
namedspaced attributes against the standard sitemap language?

<map:sitemap>
  <map:components>
    <map:blocklets>
	<map:blocklet xmlns:ac="http://apache.org/cocoon/ac/1.0" 
		      src="org.apache.cocoon.blocklet.ac.accesscontrol.sitemap.xmap"/>
    </map:blocklets>
  </map:components>


  <map:pipelines>
    <map:pipeline>
	<map:match pattern="protected/**">
	  <map:generate src="context://secret/**" ac:check="{1}"/>
	
	  <map:transform>
	  ...etc...
	</map:match>
    </map:pipeline>
  </map:pipelines>
</map:sitemap>

then in org.apache.cocoon.blocklet.ac.accesscontrol.sitemap.xmap

<map:sitemap>
  <map:components>

...standard stuff...

  </map:components>


  <map:pipelines>
    <map:pipeline name="check">
	<map:parameter name="resource"/> <!-- i don't know what to call this, but 
similar to xsl:param, declaring a parameter name -->

	<map:act type="check-logged-in">
		<map:act type="can-read-resource">
			<map:parameter name="username" value="{username}"/>
			<map:parameter name="resource" value="{../resource"/>

			<map:return/>
		</map:type>

		<map:call resource="access-denied"/>
	</map:act>

	<map:call resource="login">
	  <map:parameter name="requested-resource" value="resource"/>
	</map:call>
    </map:pipeline>
  </map:pipelines>
</map:sitemap>

    
ok, only a couple new sitemap constructs here. we have map:blocklet at the 
top, which defines the access controller, giving it a namespace to act in. 
the src attribute points to another sitemap that defines the blocklet's 
actions.

the blocklet is called when a namespaced attribute appears. the blocklet 
would be called before the generate. (potential pitfall: multiple blockets on 
a single element, what order are they called, no xml contract for attribute 
ordering afaik). the name of the attribute corresponds to the name of a 
pipeline in the blocklet sitemap. parameters could be passed either by the 
attribute contents or via the implicit parameter maps of the sitemap. in the 
first case, maybe declaring map:parameter elements under a pipeline could 
signify the order the attributes are. (the implicit params might be best..) 

then you would basically drop into a pipeline in the blocklet sitemap. the 
only new element there is a map:return element which would return control to 
the original sitemap.

rules on a blocklet pipeline could be relaxed, generators and serializers not 
required, so a blocklet call could be placed in the middle of a pipeline 
(think skin, the main contract would be an xml scheme contract, but you could 
also pass parameters to the blocklet setup in the initial sitemap, maybe 
there 
passing in the skins you want to use to the skin engine). 

rough ideas really. seems to jump out a bit more at me as far as seeming 
simple on the top. some of your previous example sketches didn't immediately 
'click' in my head, but i may just need to stare at them a bit more.

just stirring the pot.
-pete

-- 
peter royal -> proyal@managingpartners.com

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message