According to Geoff Hutchison:
> On Fri, 4 Oct 2002, Gilles Detillieux wrote:
> > However, I think in practice a lot of these are actually supposed to
> > be integer-only. I think we'd need to check over how all attributes
> > are used and label them consistently.
>
> Good point.
So I guess the question is, who will do it? :-)
> > All this raises the question of whether we should be listing CGI input
> > parameters in attrs.html (which is generated from defaults.cc). To me,
>
> Hmm. I thought one reason for doing this was to allow config-file
> overrides for most, if not all CGI input. Yes, we should probably enhance
> the hts_form.html file too, if not make it auto-generated.
Sure, any CGI input parameter that overrides its corresponding config
file attribute should be documented in attrs.html, because then they
are attributes. However, for the ones where the name is different
(e.g. format->template_name, matchesperpage->matches_per_page,
method->match_method) we should only have an entry in attrs.html for
the attribute name, not the CGI parameter name (although the description
should mention the CGI name). Also, for input parameters like config,
page, and currently "words", because these are not attributes, they
probably shouldn't be listed as such. Mind you, I can't think of a single
good reason why "words" shouldn't be a config attribute (other than the
fact it would mean changing several places where it's currently read from
"input" only).
On a related note, in Display::setVariables(), SELECTED_FORMAT
and FORMAT are set from input->get("format") rather than
config->Find("match_method"), which is another inconsistency. If we do
this properly, then the only CGI input parameters that are read from the
"input" object would be config and page, except in Display::createURL()
and the section of main() that transfers them to config.
> > to avoid opening up big security holes (see myvictim.com URL above).
> > It shouldn't be used for any attribute that defines part or all of a
> > file name. The config input parameter is checked for pathname components,
> > but none of the other input parameters are.
>
> Yes, I'm not even sure the current documentation for allow_in_form is good
> enough for this yet. Perhaps it should give an explicit example of bad
> behavior with a note explaining how you can shoot yourself in the foot.
Good point.
--
Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]>
Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/
Dept. Physiology, U. of Manitoba Winnipeg, MB R3E 3J7 (Canada)
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
htdig-dev mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/htdig-dev
