On Sunday, October 6, 2002, at 07:58 PM, Lachlan Andrew wrote:
>> The code support for author_factor, caps_factor, and >> url_text_factor is not complete, so I assume this is why >> the attributes weren't in defaults.cc. > > OK. How about including them in defaults.cc with a comment > noting they're incomplete? Sounds OK to me, provided we make an entry in the feature request tracker (and the STATUS file) that these need to be implemented. > For "filename-related" attributes, would it be worth (a) > removing a leading "/" and (b) passing it through URL.cc's > code to eliminate excess "../"s? The catch is that you don't want *any* "../" or other techniques to escape the effective chroot for the CGI. And this is different for the CGI input than for the config file. It's OK if the config file itself specifies arbitrary paths because the administrator installed it themselves. But it's not OK for the CGI input to attempt to specify arbitrary paths. I don't know if there are any good ways to handle this with allow_in_form. I've basically seen allow_in_form similar to punching a hole through your firewall. The code will let you do anything, including punch a hole in your foot. The key is whether you tell the user up front about the danger. -Geoff ------------------------------------------------------- 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
