httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk-Willem van Gulik <di...@webweaving.org>
Subject Strawman XML
Date Wed, 25 Aug 1999 14:17:44 GMT

As a sequel on the previous question.. "has anyone parsed/recorded the
apache documentation into a semantic format (such as one could use
for the configurators) or automatic generation of, say a PDF version of
the documents ??".. here is a followup:

Does anyone see great error or fundamental wrongs with the attached
strawman ? It is the result of half an hour of perl hacking and 10 minutes
of touch up. The script more or less works for all module mod_*.html
files. The example below should be complete; i.e. there is no information
lost in the transformation; and the orignal HTML can be reconstructed.

I'd like to hear some noice from people writing configurators, just to see
where they are heading.. and from people thinking of improving the doc's,
having multiple language variants, etc. 

Dw

<MODULE id="manual/mod/mod_auth">
<TITLE>
	Apache module mod_auth
</TITLE>
<SUMMARY>
	This module is contained in the <CODE>mod_auth.c</CODE> file, and
	is compiled in by default. It provides for user authentication using
	textual files.
</SUMMARY>
<SUMMARY LANG="nl">
	De mod_auth module voorziet in toegangs controle op basis van text
	bestanden met gebruikersnaam en wachtwoord gegevens.
	<p>
	Deze code voor deze module bevindt zich in het bestand <CODE>mod_auth.c</CODE>
	en maakt deel uit van de groep die standaard mee gecompileerd
	wordt. 
</SUMMARY>
<DIRECTIVE id="AuthGroupFile">
	<NAME>
		AuthGroupFile
	</NAME>
	<SYNTAX TYPE="TAKEONE">
		<ARGUMENT TYPE="filename">
			<DESCRIPTION>
		 		AuthGroupFile <EM>filename</EM> 
			</DESCRIPTION>
		</ARGUMENT>
	<CONTEXT>
		directory, .htaccess 
	</CONTEXT>
	<OVERRIDE>
		AuthConfig 
	</OVERRIDE>
	<STATUS>
		Base 
	</STATUS>
	<MODULE>
		mod_auth 
	</MODULE>
	<TOKEN>
		The AuthGroupFile directive sets the name of a textual file containing the list
		of user groups for user authentication. <EM>Filename</EM> is the path
		to the group file.  If it is not absolute (<EM>i.e.</EM>, if it
		doesn't begin with a slash), it is treated as relative to the ServerRoot.
		<P>
		Each line of the group file contains a groupname followed by a colon, followed
		by the member usernames separated by spaces. 
		<EXAMPLE>
			mygroup: bob joe anne
		</EXAMPLE>
		Note that searching large text files is <EM>very</EM> inefficient;
		<IA REF="AuthDBMGroupFile/> should be used instead.
		<P>
	</TOKEN>
	<SECURITY>
		Make sure that the AuthGroupFile is stored outside the
		document tree of the web-server; do <EM>not</EM> put it in the directory that
		it protects. Otherwise, clients will be able to download the AuthGroupFile.
	<SECURITY>
	<RELATED>
		<A HREF="core.html#authname">AuthName</A>,
		<A HREF="core.html#authtype">AuthType</A> 
		<A HREF="#authuserfile">AuthUserFile</A>
	<RELATED>
</DIRECTIVE>
<DIRECTIVE id="AuthUserFile</A>">
	<NAME>AuthUserFile</A></NAME>
	<SYNTAX TYPE="TAKEONE">
		<ARGUMENT TYPE="filename">
			<DESCRIPTION>
		 		AuthUserFile <EM>filename</EM> 
			</DESCRIPTION>
		</ARGUMENT>
	</SYNTAX>
	<CONTEXT>
		 directory, .htaccess 
	</CONTEXT>
	<OVERRIDE>
		 AuthConfig 
	</OVERRIDE>
	<STATUS>
		 Base 
	</STATUS>
	<MODULE>
		 mod_auth 
	</MODULE>
	<TOKEN>
		The AuthUserFile directive sets the name of a textual file containing
		the list of users and passwords for user
		authentication. <EM>Filename</EM> is the path to the user
		file. If it is not absolute (<EM>i.e.</EM>, if it doesn't begin with a
		slash), it is treated as relative to the ServerRoot.
		<P>
		Each line of the user file file contains a username followed
		by a colon, followed by the crypt() encrypted password. The behavior
		of multiple occurrences of the same user is undefined.
		<P>
		The utility <code>htpasswd</code> which is installed as part of the
		binary distribution, or which can be found in <code>src/support</code>,
		is used to maintain this password file. See the <code>man</code>
		page for more details. 
		<EXAMPLE>
			<code>htpasswd -c Filename username</code><br>
			Create a password file 'Filename' with 'username'
			as the initial ID. It will prompt for the password.
			<code>htpasswd Filename username2</code><br>
			Adds or modifies in password file 'Filename' the 'username'.
		</EXAMPLE>
		<P> Note that
		searching large text files is <EM>very</EM> inefficient;
		<IA REF="AuthDBMUserFile"> should be used instead.
		<P>
	</TOKEN>
	<SECURITY>
		Make sure that the AuthUserFile is stored outside the
		document tree of the web-server; do <EM>not</EM> put it in the directory that
		it protects. Otherwise, clients will be able to download the AuthUserFile.<P>
	</SECURITY>
	<RELATED>
		<A HREF="core.html#authname">AuthName</A>,
		<A HREF="core.html#authtype">AuthType</A> 
		<A HREF="#authgroupfile">AuthGroupFile</A>
	</RELATED>
</DIRECTIVE>

<DIRECTIVE id="AuthAuthoritative</A>">
	<NAME>AuthAuthoritative</A></NAME>
	<SYNTAX TYPE="TAKEONE">
		<ARGUMENT TYPE="flag">
			<DEFAULT VALUE="On"/>
			<DESCRIPTION>
	 			AuthAuthoritative &lt; <STRONG> on</STRONG>(default) | off &gt; 

			</DESCRIPTION>
		</ARGUMENT>
	</SYNTAX>
	<CONTEXT>
		 directory, .htaccess 
	</CONTEXT>
	<OVERRIDE>
		 AuthConfig 
	</OVERRIDE>
	<STATUS>
		 Base 
	</STATUS>
	<MODULE>
		 mod_auth 
	</MODULE>
	<DEFAULT>
		 By default; control is not passed on; and an unknown
		userID or rule will result in an Authorization Required reply. Not
		setting it thus keeps the system secure; and forces an NCSA compliant
		behaviour.
	</DEFAULT>
	<TOKEN>
		Setting the AuthAuthoritative directive explicitly to <STRONG>'off'</STRONG>
		allows for both authentication and authorization to be passed on to
		lower level modules (as defined in the <CODE>Configuration</CODE> and
		<CODE>modules.c</CODE> files) if there is <STRONG>no userID</STRONG>
or
		<STRONG>rule</STRONG> matching the supplied userID. If there is a userID and/or
		rule specified; the usual password and access checks will be applied
		and a failure will give an Authorization Required reply.
		<P>
		So if a userID appears in the database of more than one module; or if
		a valid require directive applies to more than one module; then the
		first module will verify the credentials; and no access is passed on;
		regardless of the AuthAuthoritative setting.
		<P>
		A common use for this is in conjunction with one of the database
		modules; such as <A
		HREF="mod_auth_db.html"><CODE>mod_auth_db.c</CODE></A>, <A
		HREF="mod_auth_dbm.html"><CODE>mod_auth_dbm.c</CODE></A>, 
		<CODE>mod_auth_msql.c</CODE>, and <A
		HREF="mod_auth_anon.html"><CODE>mod_auth_anon.c</CODE></A>. These modules
		supply the bulk of the user credential checking; but a few
		(administrator) related accesses fall through to a lower level with a
		well protected AuthUserFile.
		<P>
	</TOKEN>
	<SECURITY>
		Security: Do consider the implications of allowing a user to allow
		fall-through in his .htaccess file; and verify that this is really
		what you want; Generally it is easier to just secure a single
		.htpasswd file, than it is to secure a database such as mSQL. Make
		sure that the AuthUserFile is stored outside the document tree of the
		web-server; do <EM>not</EM> put it in the directory that it
		protects. Otherwise, clients will be able to download the
		AuthUserFile.
	</SECURITY>
	<RELATED>
		<A HREF="core.html#authname">AuthName</A>,
		<A HREF="core.html#authtype">AuthType</A> 
		<A HREF="#authgroupfile">AuthGroupFile</A>
	</RELATED>
</DIRECTIVE>
<NOTES>
</NOTES>
</MODULE>


Mime
View raw message