You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@httpd.apache.org by Dirk-Willem van Gulik <di...@webweaving.org> on 1999/08/25 16:17:44 UTC
Strawman XML
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 < <STRONG> on</STRONG>(default) | off >
</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>
Re: Strawman XML
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Tue, 7 Sep 1999, Ben Laurie wrote:
> Dirk-Willem van Gulik wrote:
> >
> > 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:
....
> > <SYNTAX TYPE="TAKEONE">
> > <ARGUMENT TYPE="filename">
> > <DESCRIPTION>
> > AuthGroupFile <EM>filename</EM>
> > </DESCRIPTION>
>
> This can't be right: the description for the whole line is nested within
> a single argument.
Hmm; this was done because this DESCRIPTION is not part of the main
directive but an explicit 'example' of this syntax in this context.
For directives like 'allow' where the parameter has five syntaxes (fqhn,
partial domain name, CIDR, full IP, partial IP) plus a fifth env syntax
this makes sense to the UI (which shows a little yellow balloon thingy).
> <EM>Filename</EM> should be a reference to the argument (forgot how you
> do that in XML).
Ah, now I understand what you are after; and then construct things like a
EXAMPLE or DESCRIPTION field per sysntax. Hmm.. that would mean a proper
XPath implementation. I've not gone much further than XSLT sofar with a
few 100 lines of perl. But yes that would be nice, and get around some of
the i18n problems I currently have (the final take _must_ do both french
and english).
> Not sure about including things like <EM> at all, anyway.
... yes.. remains of auto conversion and lazyness. Plus the fact that the
UI tool wants html for the fragments which are displayed to the user when
you want to do any markup in them.
> > <RELATED>
> > <A HREF="core.html#authname">AuthName</A>,
>
> XML refs, not HTML refs, surely?
Yes.. currently all elements/attributes not in the DTD for the xml are
silently passed on by the XSLT renderer to the UI. The UI has a widget
which knows how to display simple html. And the HREF is prefixed by the
mother's file name so the GUI has buttons to the real documentation which
pops up in a second window.
Thanks Ben, I like the idea for implicitly coding syntaxes and the lot as
references. That would be a nice and not that much extra work. Though we'd
have to check if we can then still re-generate all of the current doc's in
more or less their current format.
Dw
Re: Strawman XML
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Tue, 7 Sep 1999, Ben Laurie wrote:
> Dirk-Willem van Gulik wrote:
> >
> > 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:
....
> > <SYNTAX TYPE="TAKEONE">
> > <ARGUMENT TYPE="filename">
> > <DESCRIPTION>
> > AuthGroupFile <EM>filename</EM>
> > </DESCRIPTION>
>
> This can't be right: the description for the whole line is nested within
> a single argument.
Hmm; this was done because this DESCRIPTION is not part of the main
directive but an explicit 'example' of this syntax in this context.
For directives like 'allow' where the parameter has five syntaxes (fqhn,
partial domain name, CIDR, full IP, partial IP) plus a fifth env syntax
this makes sense to the UI (which shows a little yellow balloon thingy).
> <EM>Filename</EM> should be a reference to the argument (forgot how you
> do that in XML).
Ah, now I understand what you are after; and then construct things like a
EXAMPLE or DESCRIPTION field per sysntax. Hmm.. that would mean a proper
XPath implementation. I've not gone much further than XSLT sofar with a
few 100 lines of perl. But yes that would be nice, and get around some of
the i18n problems I currently have (the final take _must_ do both french
and english).
> Not sure about including things like <EM> at all, anyway.
... yes.. remains of auto conversion and lazyness. Plus the fact that the
UI tool wants html for the fragments which are displayed to the user when
you want to do any markup in them.
> > <RELATED>
> > <A HREF="core.html#authname">AuthName</A>,
>
> XML refs, not HTML refs, surely?
Yes.. currently all elements/attributes not in the DTD for the xml are
silently passed on by the XSLT renderer to the UI. The UI has a widget
which knows how to display simple html. And the HREF is prefixed by the
mother's file name so the GUI has buttons to the real documentation which
pops up in a second window.
Thanks Ben, I like the idea for implicitly coding syntaxes and the lot as
references. That would be a nice and not that much extra work. Though we'd
have to check if we can then still re-generate all of the current doc's in
more or less their current format.
Dw
Re: Strawman XML
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Tue, 7 Sep 1999, Ben Laurie wrote:
> Dirk-Willem van Gulik wrote:
> >
> > 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:
....
> > <SYNTAX TYPE="TAKEONE">
> > <ARGUMENT TYPE="filename">
> > <DESCRIPTION>
> > AuthGroupFile <EM>filename</EM>
> > </DESCRIPTION>
>
> This can't be right: the description for the whole line is nested within
> a single argument.
Hmm; this was done because this DESCRIPTION is not part of the main
directive but an explicit 'example' of this syntax in this context.
For directives like 'allow' where the parameter has five syntaxes (fqhn,
partial domain name, CIDR, full IP, partial IP) plus a fifth env syntax
this makes sense to the UI (which shows a little yellow balloon thingy).
> <EM>Filename</EM> should be a reference to the argument (forgot how you
> do that in XML).
Ah, now I understand what you are after; and then construct things like a
EXAMPLE or DESCRIPTION field per sysntax. Hmm.. that would mean a proper
XPath implementation. I've not gone much further than XSLT sofar with a
few 100 lines of perl. But yes that would be nice, and get around some of
the i18n problems I currently have (the final take _must_ do both french
and english).
> Not sure about including things like <EM> at all, anyway.
... yes.. remains of auto conversion and lazyness. Plus the fact that the
UI tool wants html for the fragments which are displayed to the user when
you want to do any markup in them.
> > <RELATED>
> > <A HREF="core.html#authname">AuthName</A>,
>
> XML refs, not HTML refs, surely?
Yes.. currently all elements/attributes not in the DTD for the xml are
silently passed on by the XSLT renderer to the UI. The UI has a widget
which knows how to display simple html. And the HREF is prefixed by the
mother's file name so the GUI has buttons to the real documentation which
pops up in a second window.
Thanks Ben, I like the idea for implicitly coding syntaxes and the lot as
references. That would be a nice and not that much extra work. Though we'd
have to check if we can then still re-generate all of the current doc's in
more or less their current format.
Dw
Re: Strawman XML
Posted by Ben Laurie <be...@algroup.co.uk>.
Dirk-Willem van Gulik wrote:
>
> 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>
This can't be right: the description for the whole line is nested within
a single argument.
> </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
<EM>Filename</EM> should be a reference to the argument (forgot how you
do that in XML). Not sure about including things like <EM> at all,
anyway.
> 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>,
XML refs, not HTML refs, surely?
> <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>
Same problem as above
> <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 < <STRONG> on</STRONG>(default) | off >
> </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>
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: Strawman XML
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Wed, 25 Aug 1999, Daniel Veillard wrote:
> > Does anyone see great error or fundamental wrongs with the attached
> > strawman ?
>
> I suggest the following:
>
> :1,$ s/ LANG=/ xml:lang=/g
>
> the reference being
> http://www.w3.org/TR/REC-xml#sec-lang-tag
Wow! Details! :-) Actually I had not quite reached this state... yet. Nor
thought how to deal with actual HTML markup inside human readable
sections.. or make it parsable..
It is more that I am wondering how to roughly go about this; in the
perfect world I'd like the usual things
1. the XML to be close to the C code of the modules,
auto extracting, whatever. Perhaps even -generate-
C code based on it. Almost let it act like an interface
description
2. it easy to make HTML of various flavours for the
document tree. Hence allow for a fair amounth
of making it look nice.
3. Easy(er) to cope with multiple language's without
to much managment mess of paralellel publishing
4. Easy to re-use in the various configurators people
are now making in Tk and Gnome. Or easy for validators
or other clever things.. such as allowing mod_info.
to display things even nicer..
And all of this of course happily at odds with the most important
RQ of all
5. Easy for anyone to understand and to edit, contribute,
and add to when needed.
> Basically there is a bit of cleanup needed before it gets accepted by
> a XML parser. Maybe half an hour more of work :-)
That is for sure; and not quite the aim jet. Though I am really surprized
how 'little' there is to change. Thanks for trying this !
> I would also swap all these uppercases to lowercase, but it's rather a
> personal taste :-)
Mine as well, but the apache doc's currently are almost all in caps.
Dw
PS: If this discussion gets any volume I suggest limiting it to the
docs- and gui- lists. But for now new-httpd should be reasonable.
Re: Strawman XML
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Wed, 25 Aug 1999, Daniel Veillard wrote:
> > Does anyone see great error or fundamental wrongs with the attached
> > strawman ?
>
> I suggest the following:
>
> :1,$ s/ LANG=/ xml:lang=/g
>
> the reference being
> http://www.w3.org/TR/REC-xml#sec-lang-tag
Wow! Details! :-) Actually I had not quite reached this state... yet. Nor
thought how to deal with actual HTML markup inside human readable
sections.. or make it parsable..
It is more that I am wondering how to roughly go about this; in the
perfect world I'd like the usual things
1. the XML to be close to the C code of the modules,
auto extracting, whatever. Perhaps even -generate-
C code based on it. Almost let it act like an interface
description
2. it easy to make HTML of various flavours for the
document tree. Hence allow for a fair amounth
of making it look nice.
3. Easy(er) to cope with multiple language's without
to much managment mess of paralellel publishing
4. Easy to re-use in the various configurators people
are now making in Tk and Gnome. Or easy for validators
or other clever things.. such as allowing mod_info.
to display things even nicer..
And all of this of course happily at odds with the most important
RQ of all
5. Easy for anyone to understand and to edit, contribute,
and add to when needed.
> Basically there is a bit of cleanup needed before it gets accepted by
> a XML parser. Maybe half an hour more of work :-)
That is for sure; and not quite the aim jet. Though I am really surprized
how 'little' there is to change. Thanks for trying this !
> I would also swap all these uppercases to lowercase, but it's rather a
> personal taste :-)
Mine as well, but the apache doc's currently are almost all in caps.
Dw
PS: If this discussion gets any volume I suggest limiting it to the
docs- and gui- lists. But for now new-httpd should be reasonable.
Re: Strawman XML
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Wed, 25 Aug 1999, Daniel Veillard wrote:
> > Does anyone see great error or fundamental wrongs with the attached
> > strawman ?
>
> I suggest the following:
>
> :1,$ s/ LANG=/ xml:lang=/g
>
> the reference being
> http://www.w3.org/TR/REC-xml#sec-lang-tag
Wow! Details! :-) Actually I had not quite reached this state... yet. Nor
thought how to deal with actual HTML markup inside human readable
sections.. or make it parsable..
It is more that I am wondering how to roughly go about this; in the
perfect world I'd like the usual things
1. the XML to be close to the C code of the modules,
auto extracting, whatever. Perhaps even -generate-
C code based on it. Almost let it act like an interface
description
2. it easy to make HTML of various flavours for the
document tree. Hence allow for a fair amounth
of making it look nice.
3. Easy(er) to cope with multiple language's without
to much managment mess of paralellel publishing
4. Easy to re-use in the various configurators people
are now making in Tk and Gnome. Or easy for validators
or other clever things.. such as allowing mod_info.
to display things even nicer..
And all of this of course happily at odds with the most important
RQ of all
5. Easy for anyone to understand and to edit, contribute,
and add to when needed.
> Basically there is a bit of cleanup needed before it gets accepted by
> a XML parser. Maybe half an hour more of work :-)
That is for sure; and not quite the aim jet. Though I am really surprized
how 'little' there is to change. Thanks for trying this !
> I would also swap all these uppercases to lowercase, but it's rather a
> personal taste :-)
Mine as well, but the apache doc's currently are almost all in caps.
Dw
PS: If this discussion gets any volume I suggest limiting it to the
docs- and gui- lists. But for now new-httpd should be reasonable.
Re: Strawman XML
Posted by Daniel Veillard <Da...@w3.org>.
> Does anyone see great error or fundamental wrongs with the attached
> strawman ?
I suggest the following:
:1,$ s/ LANG=/ xml:lang=/g
the reference being
http://www.w3.org/TR/REC-xml#sec-lang-tag
Fragment of html included in the output should be cleaned up, for example
the <p> included in line 17 generates a well-formedness error making
the full piece unusable (a parser must not recover on those kind of errors).
The simplest (and ugliest) is to escape all html constructs in the
content s/</</g in the content may do the trick.
Also
<DIRECTIVE id="AuthUserFile</A>">
is not allowed, the < must be escaped even in attributes values.
<IA REF="AuthDBMGroupFile/>
lacks the closing double-quote
line 64:
<RELATED>
should be a closing declaration
Basically there is a bit of cleanup needed before it gets accepted by
a XML parser. Maybe half an hour more of work :-)
I would also swap all these uppercases to lowercase, but it's rather a
personal taste :-)
Daniel
--
Daniel.Veillard@w3.org | W3C, INRIA Rhone-Alpes | Today's Bookmarks :
Tel : +33 476 615 257 | 655, avenue de l'Europe | Linux, WWW, rpmfind,
Fax : +33 476 615 207 | 38330 Montbonnot FRANCE | rpm2html, XML,
http://www.w3.org/People/W3Cpeople.html#Veillard | badminton, and Kaffe.
Re: Strawman XML
Posted by Daniel Veillard <Da...@w3.org>.
> Does anyone see great error or fundamental wrongs with the attached
> strawman ?
I suggest the following:
:1,$ s/ LANG=/ xml:lang=/g
the reference being
http://www.w3.org/TR/REC-xml#sec-lang-tag
Fragment of html included in the output should be cleaned up, for example
the <p> included in line 17 generates a well-formedness error making
the full piece unusable (a parser must not recover on those kind of errors).
The simplest (and ugliest) is to escape all html constructs in the
content s/</</g in the content may do the trick.
Also
<DIRECTIVE id="AuthUserFile</A>">
is not allowed, the < must be escaped even in attributes values.
<IA REF="AuthDBMGroupFile/>
lacks the closing double-quote
line 64:
<RELATED>
should be a closing declaration
Basically there is a bit of cleanup needed before it gets accepted by
a XML parser. Maybe half an hour more of work :-)
I would also swap all these uppercases to lowercase, but it's rather a
personal taste :-)
Daniel
--
Daniel.Veillard@w3.org | W3C, INRIA Rhone-Alpes | Today's Bookmarks :
Tel : +33 476 615 257 | 655, avenue de l'Europe | Linux, WWW, rpmfind,
Fax : +33 476 615 207 | 38330 Montbonnot FRANCE | rpm2html, XML,
http://www.w3.org/People/W3Cpeople.html#Veillard | badminton, and Kaffe.
Re: Strawman XML
Posted by Andrew Ford <an...@icarus.demon.co.uk>.
dirkx@webweaving.org (Dirk-Willem van Gulik) writes:
> 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.
>
I am in the process of converting the Apache and mod_perl Quick
Reference Cards to use the DocBook SGML DTD with some additions for
the directive information. This will first of all feed into the
"Apache Pocket Reference" I am writing for O'Reilly and then into the
quick reference cards. To give a flavour, here are a couple of the
directives marked up:
<!ENTITY apdir.directory
'<apdirinfo name = "Directory"
container = "yes"
module = "http_core"
status = "CORE"
context = "cv">
<apsyntax>
<alternatives>
<choice>
<metavar>&apmeta.pattern;</metavar>
</choice>
<choice>
<optional>~</optional> <metavar>regex</metavar>
</choice>
</alternatives>
</apsyntax>
</apdirinfo>' >
<!ENTITY apdir.documentroot
'<apdirinfo name = "DocumentRoot"
container = "no"
module = "http_core"
status = "CORE"
context = "cv">
<apsyntax>
<metavar>&apmeta.dirname;</metavar>
</apsyntax>
<apdefault>
<literal>&apdef.documentroot;</literal>
</apdefault>
</apdirinfo>' >
The directives are defined as entities so the semantic information can
be included wherever needed. The metavariables are also included as
entities to facilitate translation. If set to English the entity
apmeta.pattern is defined as "pattern"; if set to German then it is
defined as "Muster", etc.
Your XML looks OK to me.
Regards
Andrew
--
Andrew Ford, Director Ford & Mason Ltd +44 1531 829900 (tel)
A.Ford@ford-mason.co.uk South Wing, Compton House +44 1531 829901 (fax)
http://www.ford-mason.co.uk Compton Green, Redmarley +44 385 258278 (mobile)
http://www.refcards.com Gloucester, GL19 3JB, UK
Re: Strawman XML
Posted by David Reid <ab...@dial.pipex.com>.
Dirk,
Took about 10 mins of quick hacks to get IE5 to display it. All the changes
I had to make were covered by Daniels email. If this is to go further then
will should a DTD be developed and registered? It'll make peoples lives
easier when they come to write some docs :-)
david
----- Original Message -----
From: Dirk-Willem van Gulik <di...@webweaving.org>
To: <ap...@apache.org>; <gu...@apache.org>; <ne...@apache.org>
Sent: 25 August 1999 15:17
Subject: Strawman XML
>
> 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 < <STRONG> on</STRONG>(default) | off >
> </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>
>
Re: Strawman XML
Posted by Ben Laurie <be...@algroup.co.uk>.
Dirk-Willem van Gulik wrote:
>
> 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>
This can't be right: the description for the whole line is nested within
a single argument.
> </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
<EM>Filename</EM> should be a reference to the argument (forgot how you
do that in XML). Not sure about including things like <EM> at all,
anyway.
> 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>,
XML refs, not HTML refs, surely?
> <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>
Same problem as above
> <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 < <STRONG> on</STRONG>(default) | off >
> </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>
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: Strawman XML
Posted by Ben Laurie <be...@algroup.co.uk>.
Dirk-Willem van Gulik wrote:
>
> 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>
This can't be right: the description for the whole line is nested within
a single argument.
> </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
<EM>Filename</EM> should be a reference to the argument (forgot how you
do that in XML). Not sure about including things like <EM> at all,
anyway.
> 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>,
XML refs, not HTML refs, surely?
> <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>
Same problem as above
> <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 < <STRONG> on</STRONG>(default) | off >
> </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>
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: Strawman XML
Posted by Rich Roth <ri...@on-the-net.com>.
On Sat, 4 Sep 1999, sehh of H.I.C. & D.B.S. wrote:
> I am the author of ServerConfig/2, GUI config util for OS/2. What i was
> looking for, was a 'version' of the Apache documentation which could be
> compiled under the OS/2 help file
> Another important issue is portability, HTML is a good choice since it
> can be converted into many other formats, like online Help facilities,
> unlike PDF which needs a PDF viewer and can't be called within a program
> as online help.
Actually HTML is not a good base for conversion since it does not have a
lot of the information in a format converters can handle very acurrately
for a wide range of uses.
> XML is a good choice, but you have to consider that the Apache
> documentation must also exist online in Apache's website, and HTML is a
> more suitable format since it can be browsed by older browsers.
It is far simplier to convert HTML to XML than HTML to XML and other
formats - XML contains information that HTML doesn't and is better formed
producing more accurate results. There are a number of tools to convert
XML to HTML plus newer browsers can display XML directly.
net-net: I think you have it backward, the better way is to use the more
advanced and standardized format (XML) and include HTML in one of the
standard renderings.
Later ...
Rich Roth --- On-the-Net
Direct: Box 927, Northampton, MA 01061, Voice: 413-586-9668
Email: rich@on-the-net.com Url: http://east.on-the-net.com
~~~ i-Depth lets you Add Instant Depth to your Website ~~~
~~~ 7 day free trial at: http://www.i-depth.com/signup.htm ~~~
Re: Strawman XML
Posted by Rich Roth <ri...@on-the-net.com>.
On Sat, 4 Sep 1999, sehh of H.I.C. & D.B.S. wrote:
> I am the author of ServerConfig/2, GUI config util for OS/2. What i was
> looking for, was a 'version' of the Apache documentation which could be
> compiled under the OS/2 help file
> Another important issue is portability, HTML is a good choice since it
> can be converted into many other formats, like online Help facilities,
> unlike PDF which needs a PDF viewer and can't be called within a program
> as online help.
Actually HTML is not a good base for conversion since it does not have a
lot of the information in a format converters can handle very acurrately
for a wide range of uses.
> XML is a good choice, but you have to consider that the Apache
> documentation must also exist online in Apache's website, and HTML is a
> more suitable format since it can be browsed by older browsers.
It is far simplier to convert HTML to XML than HTML to XML and other
formats - XML contains information that HTML doesn't and is better formed
producing more accurate results. There are a number of tools to convert
XML to HTML plus newer browsers can display XML directly.
net-net: I think you have it backward, the better way is to use the more
advanced and standardized format (XML) and include HTML in one of the
standard renderings.
Later ...
Rich Roth --- On-the-Net
Direct: Box 927, Northampton, MA 01061, Voice: 413-586-9668
Email: rich@on-the-net.com Url: http://east.on-the-net.com
~~~ i-Depth lets you Add Instant Depth to your Website ~~~
~~~ 7 day free trial at: http://www.i-depth.com/signup.htm ~~~
Re: Strawman XML
Posted by "sehh of H.I.C. & D.B.S." <se...@altered.com>.
On Wed, 25 Aug 1999 16:17:44 +0200 (CEST), Dirk-Willem van Gulik wrote:
>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.
I am the author of ServerConfig/2, GUI config util for OS/2. What i was looking for, was
a 'version' of the Apache documentation which could be compiled under the OS/2 help file
format. Which ofcourse i did my converting HTML into that format (.IPF). Although its not
a perfect copy of the HTML code, it gives me the base to modify it any way i want.
This is not much use to most of you since you don't use OS/2, but i just wanted to say that
a platform/os-independend documentation would be the best option for everyone.
Another important issue is portability, HTML is a good choice since it can be converted into
many other formats, like online Help facilities, unlike PDF which needs a PDF viewer and can't
be called within a program as online help.
XML is a good choice, but you have to consider that the Apache documentation must also exist
online in Apache's website, and HTML is a more suitable format since it can be browsed by
older browsers.
� H.I.C. & D.B.S. � OS/2 Warp � Hellas �
� ServerConfig � InfoHICmag � OS/2 UK UG �
� Windows - The Gates of hell.
Re: Strawman XML
Posted by "sehh of H.I.C. & D.B.S." <se...@altered.com>.
On Wed, 25 Aug 1999 16:17:44 +0200 (CEST), Dirk-Willem van Gulik wrote:
>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.
I am the author of ServerConfig/2, GUI config util for OS/2. What i was looking for, was
a 'version' of the Apache documentation which could be compiled under the OS/2 help file
format. Which ofcourse i did my converting HTML into that format (.IPF). Although its not
a perfect copy of the HTML code, it gives me the base to modify it any way i want.
This is not much use to most of you since you don't use OS/2, but i just wanted to say that
a platform/os-independend documentation would be the best option for everyone.
Another important issue is portability, HTML is a good choice since it can be converted into
many other formats, like online Help facilities, unlike PDF which needs a PDF viewer and can't
be called within a program as online help.
XML is a good choice, but you have to consider that the Apache documentation must also exist
online in Apache's website, and HTML is a more suitable format since it can be browsed by
older browsers.
� H.I.C. & D.B.S. � OS/2 Warp � Hellas �
� ServerConfig � InfoHICmag � OS/2 UK UG �
� Windows - The Gates of hell.