According to Gilles Detillieux:
>According to Torsten Neuer:
>> According to Geoff Hutchison:
>> >I don't know of how security would benefit from a module, but I imagine
>> >there might be benefits there.
>>
>> Security benefits will mainly come from hiding away the "restrict",
>> "exclude" and "config" parameters of htsearch. I remember that
>> methods of hiding these parameters from the end user for better
>> security of internal pages have been discussed on the htdig mailing
>> list not too long ago.
>
>If security is the main goal here, how about adding a disallow_in_form
>attribute to prevent users from using certain input parameters, like
>restrict and exclude. (The allow_in_form attribute that Leo added to
>htsearch allows you to specify which configuration attributes can be
>overridden by input parameters. What I'm proposing would be slightly
>different, in that it doesn't have anything to to with configuration
>attributes, but rather it affects the current set of allowed input
>parameters.) This wouldn't work for the "config" parameter, as
>htsearch wouldn't see the disallow_in_form attribute until it reads
>the configuration file. This isn't a huge problem, as htsearch already
>limits config to a specific directory, selected as compile time. If you
>want to make this more restrictive, there are a couple options.
My idea was to control the htsearch module from httpd.conf but
still use the htdig.conf, so we can control the configuration
file to be used on a per-directory basis.
This isn't neccessarily a restriction with regards to selecting
different configuration files from one search form, since you
can set up virtual locations that are handled by htsearch with
different configurations.
Disallow_In_Form is therefore not neccessary for the module.
However, it might be a security improvement to the htsearch CGI.
My approach also does not mess with configuration attributes in
general, but to control most of the form parameters from httpd.conf
instead of the search form. Such a configuration could look like
<Location /internal-query>
SetHandler htdig-query
Order deny,allow
Deny from all
Allow from localhost
htsearch_Config intranet
</Location>
<Location /external-query>
SetHandler htdig-query
Allow from all
htsearch_Config internet
htsearch_Restrict /all/but/secret/stuff
</Location>
>1) Change htsearch.cc to ignore the config input parameter. This could
>be made easier by a compile-time option, but it's not that difficult as
>it is.
Which would lead to multiple copies of htsearch on bigger sites
and the need to recompile htsearch for every change that is done
to the web space of this site. IMHO this is not very handy for
maintenance purposes.
>2) Make htsearch.cc read a specific configuration file (e.g. htdig.conf
>or .htdig.conf) before reading the one specified by "config". This would
>allow a runtime option (e.g. disallow_in_form attribute) to disable user
>selection of alternate configurations.
Same restrictions apply to this solution.
Controlling htsearch configuration from the HTTP server configuration
is therefore much more flexible. Why would we want to invent the
wheel over and over again?
Of course, your solution is more platform independant, but that
does not neccessarily mean that an Apache module isn't a better
way of doing it on Apache platforms ;-)
cheers,
Torsten
--
InWise - Wirtschaftlich-Wissenschaftlicher Internet Service GmbH
Waldhofstra�e 14 Tel: +49-4101-403605
D-25474 Ellerbek Fax: +49-4101-403606
E-Mail: [EMAIL PROTECTED] Internet: http://www.inwise.de
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED] containing the single word "unsubscribe" in
the SUBJECT of the message.
