Greg Weinger wrote: <snip/> > > 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 (ftp://ftp.isi.edu/in-notes/rfc2617.txt), 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 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? 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
