cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Negative Matching Constructs && Mime Type Matching
Date Fri, 30 Nov 2001 13:36:02 GMT
Berin Loritsch wrote:
> 
> Stefano Mazzocchi wrote:
> 
> > Berin Loritsch wrote:
> >
> >
> >
> >>What did you think about being able to *explicitly* raise an error from the sitemap?
> >>
> >
> > Uh, I probably missed that. What do you mean?
> 
> In my psuedo-sitemap markup I used a new element:
> 
> <map:generate-error type="404"/>
> 
> This can give you fine control over the types of return errors that an application
> will give.  It will also allow you *explicitly* state what you are expecting to do
> rather than implicitly trust the sitemap to do the right thing.  It could be that
> the Servlet environment's authentication is not flexible enough for you (shocking
> isn't it?).
> 
> The Servlet environment provides you with three options for authentication:
> 
> BASIC (Hopefully everyone avoids this...)
> Form  (same thing, except now you have a nice wrapper on it)
> PKI   (the first oportunity to use something more flexible)
> 
> The problem with the first two is that you are dealing with cear-text (or a base-64
> representation of it)--not very secure.  Also you are limited to username/password.
> We have very sophisticated session management tools at our disposal these days, and
> it might be worth playing around with Cocoon based authentication modules--or possibly
> even a wrapper around JAAS.
> 
> The problem is now you need to be able to explicitly raise the "401 Unauthorized"
> HTTP response if they get it wrong.  The current Sitemap topology CANNOT do this.
> It can at best give you "404" and "500" automatically--but nothing more expressive.

I see. Sounds very powerful and elegant.

But what about <map:throw error="404"> instead? "generate-error"
conflicts semantically with the generators.

> >>This is only implemented for the servlet environment.  There is no way to have
a standard suite
> >>of mime-mappings independently of the environment.  IOW, the Servlet environment
has it's way,
> >>the CLI environment has another way (or ignores it), a Block embedded Cocoon
would have yet
> >>another way.
> >>
> >>Do you see the conundrum?
> >>
> >
> > Yep. So, do you propose to have a mime-mapper Avalon component?
> >
> > [note that the Cocoon CLI already performs the reverse mapping between
> > mime/type and extension, so we need a component that is able to obtain
> > an extension for a mime type and a mime type from an extension]
> 
> Actually that is exactly what I was proposing :)
> 
> It should probably live in Excalibur--which is getting quite big.  We might
> have to investigate breaking it into smaller swords as a packaging option ;p.

Sounds great to me. Are you volunteering? ;-)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



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


Mime
View raw message