cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Weinger" <>
Subject RE: [RT] Access Control (was [RT] Cocoon as OS)
Date Thu, 07 Feb 2002 01:20:50 GMT
> The servlet API is (AFAIU) based on an authorization model where
> the servlet container is suposed to take care about:
> * the HTTP authentication protocol (
> notes/rfc2617.txt)
> * user authorization (in practice: user and password DB)
> * role handling
> IMHO the first point is an appropriate concern for the servlet
> while the rest of the points are application concerns. 

Right.  It's nice that Tomcat provides user authorization, but relying
on it makes your apps less portable.  

> > I started with the User/Group based system, since it is
> > ubiquitous.  (I think
> > Brian was touching on this earlier).  To bring that to the
> > Cocoon/web world, we
> > need to assume that every URI request has a user, password, and a
> > group.  If this
> > information does not exist in the standard places (Request,
> > Session, or a new
> > User object in the object model), than a default user, password,
> > and group is
> > assumed (anonymous).  That means we'd have "special" request
> > parameters, a la
> > cocoon-action, cocoon-user, cocoon-pass, cocoon-group, which is
> > ugliness to be
> > sure, but ugliness that goes away with Schecoon.
> It seem a little bit complicated (and insecure) to make shure that the
> client send all this information, (but maybe I am missing something).
> Browsers know about the HTTP authentication protocol, and if you use
> they will send you username and password automatically.

Where do you retrieve them? AFAIK they're not available in the Servlet

Anyway, graphic designers loathe the HTTP authentication protocol.  Your
only choice of input form is that gray box that pops-up (maybe not in
mozilla XUL, but the world isn't there yet).  In most cases, you'll be
wanting to use HTTP forms.  

The main problem, I think, is that HTTP requests on their own do not
have the concept a user built into it, which is necessary to perform
user-based access control.  That information has to be established
programmatically.  My thought was, what if we built that concept into

> I think that what you propose here can be handled with actions, so
> is
> probably no need for new sitemap constructions, although they could be
> more
> conscise.

That's what I was wondering; it's not necessary, but if AC is used so
frequently, for almost every URI, would that concision be useful?

To unsubscribe, e-mail:
For additional commands, email:

View raw message