According to Torsten Neuer:
> According to Frank Guangxin Liu:
> >I have some ideas about this username/password thing.
> >We can put those information in a separate file (only
> >readable to root, or whoever runs the "htdig" task).
> >The password file can have three columns,
> >siteURL username password
> >Multiple lines are allowed so that "htdig" can dig different
> >sites(URL) with different username/password. This is an improvement
> >over the old htdig where only ONE username/password can be
> >specified.
> >We can also make a special entry for "siteURL" column, say,
> >a dash "-", or a word "default", which means that this line
> >(username/password) will be used if no matching siteURL entry
> >can be found for a site that requires authentication.
> >
> >We can even modify the -u option to "htdig". If this option
> >has : in it (say username:pass), use the old way, otherwise,
> >treat it as the filename of the password file. If it has a
> >leading /, treat it as an absolute filename, otherwise, a
> >filename relative to CONFIG_DIR
> >
> >Frank
>
> If we are going to use such a file, we could possibly also use
> existing resources, like the ftp ~/.netrc file. However, this
> could imply splitting up ht://Dig configuration and access in-
> formation, which might not be useful.
I like Frank's suggestion, but rather than forcing the user to use a
separate file, I'd prefer to see this as a conventional htdig attribute,
whose value is a list of string triplets. E.g.:
site_passwords: pattern1 username1 password1 \
pattern2 username2 password2
Then, if the user prefers a separate file, this would work:
site_passwords: `/etc/htdig/sitepasswd`
where the file could be a list of space or tab separated triplets:
pattern1 username1 password1
pattern2 username2 password2
This is more consistent with the way the configuration file is currently
handled. Of course, this may change if we implement the <URL ...>
mechanism for site-specific configurations.
The important thing would be for the documentation to recommend using
a separate file for this attribute, and to recommend emphatically that
in any case, files that contain clear-text passwords should always be
read-protected.
For handling the default case, you could just use a pattern that would
be sure to match, e.g:
http:// defuser defpassword
and leave it to htdig to pick the first pattern that matches. As long
as patterns are arranged from strictest to loosest, you can get htdig
to do what you want. (This is how the case statement in the Bourne
shell works.) Of course, we could also allow regular expressions,
as we do now with a lot of patterns in the 3.2 code.
--
Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]>
Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/~grdetil
Dept. Physiology, U. of Manitoba Phone: (204)789-3766
Winnipeg, MB R3E 3J7 (Canada) Fax: (204)789-3930
------------------------------------
To unsubscribe from the htdig mailing list, send a message to
[EMAIL PROTECTED] containing the single word "unsubscribe" in
the SUBJECT of the message.
