cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allan Erskine <a.ersk...@cs.ucl.ac.uk>
Subject Re: [C2] Protected area app
Date Mon, 23 Apr 2001 13:26:42 GMT
> No, the {1} references the nearest parent and {../1} his parent so on.

ahh - ok.  This is much better...

Does the same go for nested actions?  (For sequential actions the returned
maps are composed, right?)

Allan

----- Original Message -----
From: "giacomo" <giacomo@apache.org>
To: "cocoon-dev" <cocoon-dev@xml.apache.org>
Sent: Monday, April 23, 2001 6:13 AM
Subject: Re: [C2] Protected area app


>
>
> On Mon, 23 Apr 2001, Allan Erskine wrote:
>
> > session validation in every map:match fragment?  I haven't thought of
one
> > myself, but if you could be assured that the following sort of fragment
> > > > >
> > > > > <map:match pattern="protected**">
> > > > >     <session validator action>
> > > > >         <any protected content generated/>
> > > > >     </session validator action>
> > > > >     <action failed>
> > > > >         <back to login/>
> > > > >     </action failed>
> > > > > </map:match>
> > > > >
> > > > > were always evaluated before any protected content, surely this
would
> > be all it would take?  I'm probably missing something....
> > > > No problem. Replace the <any protected content.../> above with a
<mount>
> > > > element.
> > > >
> > >
> > > wow, even me when designing these actions I haven thought about this
and
> > now I
> > > found it very promissing :))
> >
> > Another approach you could try is just with nested matchers
> >
> > <map:match pattern="protected**">
> >      <session validator action>
> >         <map:match pattern="protected/page1">
> >
> >         </map:match>
> >
> >         <map:match pattern="protected/page2">
> >
> >         </map:match>
> >
> >      </session validator action>
> >      <action failed>
> >         <back to login/>
> >      </action failed>
> > </map:match>
> >
> > Seems to work quite well....one thing I'm unsure of though is what
happens
> > to values from matchers...if an internal wildcard matcher also matched
**,
> > I'm banking on {1} being temporarily overridden for the scope of the
> > matcher, the same going for an action's map values...... this belief is
pure
> > faith on my part though - I haven't researched it... hope I'm right!
>
> No, the {1} references the nearest parent and {../1} his parent so on.
>
> Giacomo
>
> >
> > Allan
> >
> >
> > ----- Original Message -----
> > From: "Martin Man" <Martin.Man@seznam.cz>
> > To: <cocoon-dev@xml.apache.org>
> > Sent: Friday, April 20, 2001 8:11 PM
> > Subject: Re: [C2] Protected area app
> >
> >
> > > On Thu, Apr 19, 2001 at 07:05:53AM +0200, giacomo wrote:
> > > >
> > > >
> > > > On Thu, 19 Apr 2001, Allan Erskine wrote:
> > > >
> > > > > Regarding Martin's comment inside the protected area (it's been a
> > useful example for me - thanks!!), is there no clever way a matcher or
> > selector can capture the aspect of repeated session validation in every
> > map:match fragment?  I haven't thought of one myself, but if you could
be
> > assured that the following sort of fragment
> > > > >
> > > > > <map:match pattern="protected**">
> > > > >     <session validator action>
> > > > >         <any protected content generated/>
> > > > >     </session validator action>
> > > > >     <action failed>
> > > > >         <back to login/>
> > > > >     </action failed>
> > > > > </map:match>
> > > > >
> > > > > were always evaluated before any protected content, surely this
would
> > be all it would take?  I'm probably missing something....
> > > > >
> > > > > For instance how about mounting a sitemap that doesn't care about
> > security, only if the validation on a security checking sitemap is
> > passed....?
> > > >
> > > > No problem. Replace the <any protected content.../> above with a
<mount>
> > > > element.
> > > >
> > >
> > > wow, even me when designing these actions I haven thought about this
and
> > now I
> > > found it very promissing :))
> > >
> > > > Giacomo
> > > >
> > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > > >
> > >
> > > --
> >
> --------------------------------------------------------------------------
> > -----
> > > "Only dead fish swims with a stream"
> > > gpg_key_available: http://globales.cz/~mman/martin.man.gpg
> > > gpg_key_fingerprint: 2CC0 4AF6 92DA 5CBF 5F09  7BCB 6202 7024 6E06
0223
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


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


Mime
View raw message