httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Terbush <ra...@zyzzyva.com>
Subject Re: Let's get rid of .htaccess files :-)
Date Thu, 18 Jul 1996 15:36:31 GMT
> Randy Terbush writes:
>  > 
>  > You would only need to parse the tree at startup and SIGHUP.
>  > It would be very easy to have a separate daemon watching the
>  > conf/ for changes and sending a SIGHUP when needed. The conf/
>  > could even be a DBM format file, however I prefer the idea
>  > of leaving it accessible by basic system tools like 'vi'.
>  > Hell, I could even imagine an Emacs mode for configuring the
>  > server! :-)
> 
> Hmm, I like this idea, only why bother with lots of files. Why not just
> have on access.conf file that has auth information for a URL (with regex
> matching). This would be parsed once at startup so it's complexity is
> less of an issue and if you make a change you have to re-hup. You could
> also provide an online tool to edit the internal access table directly
> for immediate changes and have the server write out a new access file 
> if you wished (or periodically perhaps, make it all configurable).

The reasoning for using the filesystem was to use the system's
built in access control to control who has permissions to edit
config files. If the ownership of the conf/ directory tree mirrors
that of the webspace, the problem is solved. From the standpoint of
writing a configuration tool, it seems that locking issues etc. 
become much less of an issue.

> This would be a really nice feature, if it's suitably abstracted the
> access file can be replaced by anything we want, like an Oracle database
> which is what I'm doing a lot of work with at the moment.

I agree. As I reworked the read_configdir(), it occured to me that
ConfigDir (or ConfigDB) could point to any number of file formats
to allow DBM, SQL database, etc.

> In fact, authentication is top of my agenda at the moment, I need to do
> far more complex things than just access authentication, such as credit
> accounting and so forth, different access to different bits of
> information that are all served up in a single dynamically generated
> page using cgi etc.

My mind wanders back to the SQL approach....
Why couldn't log info and config info point to a database fully of
keys indexed by directory path. Each path would store a record for
file accesses, data transfered, config info, etc.

> The "standard" access methods are woefully inedaquate.




Mime
View raw message