httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@ai.mit.edu (Robert S. Thau)
Subject Re: Authentication API
Date Wed, 17 Jul 1996 21:22:02 GMT
  > However, it seems to me that if this is what you're trying to do,
  > it's better engineering to try to find an approach which is not limited
  > to authentication and access control --- mod_mime and mod_dirs can be
  > reconfigured per-directory as well, and they might as well be approachable
  > through the same interface.

  Agreed. My thought has been that tackling one portion of this might
  lead to greater enlightenment.

Well, doing that sort of thing is sometimes a good idea, but only if
you're committed to the notion in advance that when you've achieved
enlightenment, you'll go back and do the whole thing right, meaning
tossing whatever is particular to access control and rewriting those
sections from scratch.  (Throwing away first-draft code is good
discipline generally, of course).

Coming up with one hack for access control and auth, and then fishing
around for a different hack for the next batch of modules, and so forth,
leaves you with a collection of hacks.  If the goal is a comprehensive
solution, it needs to be designed that way from the start.

  > This would require something like mod_info to tell the reconfigurer
  > what commands are allowed by the server as currently configured. so it
  > could parse what it had written.  However, it doesn't get into issues
  > of trying to unparse the modules' private internal data structures.

  This is the area that has me stumped. It sounds like it is not
  going to be possible in the current code?

I'm not sure which of these things you're asking about.

Getting mod_info to give you a grammar for text commands is possible;
unfortunately, that grammar wouldn't as specific as one would
generally like --- particularly for the (mercifully few) commands
which take RAW_ARGS (i.e., unparsed arguments); defining more
tractable alternative versions might be a good thing.

Getting access to modules' private data is currently very difficult,
if not impossible.  However, if the thing ultimately works by
producing config files which the server reads using anything like its
ordinary means, it isn't strictly necessary --- you can just parse the
current copy of the config file in question.

  My intent has not been to "tweak" it, but rather use the server's
  parsing tools to get at information that it must know for every
  request. My initial plan was to rewrite the .htaccess files, but
  as you have pointed out many times, that is an area of the server
  that could seriously benefit from reworking access control.

But the modules' private data really is private.  The intention always
was to let people writing a module choose whatever format for parsed
configuration info suited their purposes, for greatest efficiency.
Specifically, I wanted to avoid continually reparsing the central
config files in the course of handling every request, as would be
effectively required if that data were kept in some sort of
standardized form.

(Besides, what would that look like?  About all that one module can
"understand" of anothers' commands without deep knowledge of what that
module does and how is that a particular command was invoked with
particular arguments.  If that's all you want, you could get it by
saving the raw text of the config files, if you liked, but at the cost
of some bloat in the memory usage --- one copy per running server
process, remember).

rst







Mime
View raw message