cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] Access Control (was [RT] Cocoon as OS)
Date Thu, 07 Feb 2002 09:53:08 GMT
Greg Weinger wrote:
> > Browsers know about the HTTP authentication protocol, and if you use
> that,
> > they will send you username and password automatically.
> Where do you retrieve them? AFAIK they're not available in the Servlet
> API.
You can use getAuthType(), getRemoteUser(), getUserPrincipal(),
and isUserInRole(java.lang.String role) in the HttpServletRequest interface.
Password is however not availible as all the above methods rely on that
the servlet container takes care of user authentication.

> 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.
Yes it is disturbing that one have to choose between design and security
level: Form based login is ok if you use HTTPS or if you don't think (or
care if) someone taping your wire. HTTP digest authentication gives you
much higher security level of security against wire tapping if you don't
want to use HTTPS, but in this case you will get gray box pop-ups in the
browser :(

> 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.
They have, see (, for all the
technical details ;). But it depends on that the browser takes care of
the protocol, which leads to: gray box pop-ups.

> That information has to be established programmatically.  My thought
> was, what if we built that concept into Cocoon?
Yes, then I think that one either have to suport rfc2617 in Cocoon, which
seem tricky, or use session based security, (IIRC there already are som
actions in Cocoon that takes care of that). Implementing own support for
passing credentials back and forth for each request, seem to complicated
to me.

> > I think that what you propose here can be handled with actions, so there
> > is probably no need for new sitemap constructions, although they could
> > 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?
IMHO as it is possible to experiment with the things that you are sugesting
without extending any sitemap concepts, it is better to do that, concision
is not a goal in it self. However if you want to be able to ask Cocoon about
security, "ls -l", as you sugested in your RT (Cocoon as OS), it seems
nescesary to have an explicit description of the AC rules. This would
also be useful if one want WebDAV access to Cocoon (where "ls -l"
corresponds to PROPFIND with some kind of ACL argument), I should add, that
"ls" is hard (to say the least) to integrate in Cocoon as you can use
wildcards in the sitemap (Berin and Stefano had recently a discussion
about something related in the context of hash table based "map:match"
implementation in the sitemap, don't rememeber in what thread).

/Daniel Fagerstrom

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

View raw message