> The servlet API is (AFAIU) based on an authorization model where > the servlet container is suposed to take care about: > > * the HTTP authentication protocol (ftp://ftp.isi.edu/in- > notes/rfc2617.txt) > * user authorization (in practice: user and password DB) > * role handling > > IMHO the first point is an appropriate concern for the servlet container > 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 that, > they will send you username and password automatically. Where do you retrieve them? AFAIK they're not available in the Servlet API. 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 Cocoon? > 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? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
