Closed Bug 117936 Opened 23 years ago Closed 22 years ago

.htaccess files for Apache 1.2.x (<Files>, not <FilesMatch>)


(Bugzilla :: Documentation, enhancement, P3)




Bugzilla 2.16


(Reporter: afranke, Assigned: bz)


Since the <FilesMatch...> directive is only available in Apache 1.3, the
.htaccess files generated by checksetup don't work with Apache 1.2.x.

When I use 
	<Files ~ "..."> ... </Files> 
instead of 
	<FilesMatch ^...> ... </FilesMatch>
it seems to work for me:

- change FilesMatch -> Files
- add the ~ and a space before the regexp
- quote the regexp with "..."
- finally, drop the ^

Here are the results:

1. .htaccess in the root directory:
# don't allow people to retrieve non-cgi executable files or our private data
<Files ~ "(.*\.pl|localconfig|processmail|syncshadowdb|$">
  deny from all

2. .htaccess in the data directory (no changes necessary):
# nothing in this directory is retrievable unless overriden by an .htaccess
# in a subdirectory
deny from all

3. .htaccess in the data/webdot directory:
# Allow access to nothing in this directory except for .dot files
# and don't allow access to those to anyone except
# if ever changed their IP, or if you use a different
# webdot server, you'll need to edit this
<Files ~ "[0-9]+\.dot$">
  Allow from
  Deny from all
# And no directory listings, either.
Deny from all
What is gained by dropping the ^ ?  Does Apache 1.2 choke on that?  the ^ is in
theory necessary to gain an exact filename match on the items that don't have
wildcards in them, though I suppose there's no harm in blocking any file that
ends with "localconfig", which is the effect of dropping that ^
Yes, adding the ^ right before the opening bracket apparently causes my apache
1.2 to ignore the entire directive, at least my localconfig file is not
protected any more if I don't drop the ^. I know the theoretical effect of
dropping the ^, but it shouldn't do any harm in the actual case.
Note that since FilesMatch is the recommended way now, the cleanest solution
would be to have two different versions of .htaccess files. But then you'd
probably have to prompt the user for their apache version at installation time,
and then bugzilla wouldn't get notified when the user upgrades Apache... So I
guess this problem doesn't have an ideal solution.
We should do something here for 2.16.  At the very least document it doesn't
work.  Perhaps this can become a permanent deprecation.

Dave says on IRC Apache 1.2 has security problems and should not be supported.
Priority: -- → P3
Target Milestone: --- → Bugzilla 2.16
Given that Apache 2.0 has been released, and says
1.3.24 is the latest 1.x version (which is a security release), I think we can
deprecate 1.2 in the docs.

Over to barnboy.

Assignee: justdave → barnboy
Component: Bugzilla-General → Documentation
Reassigning bugs from to
Assignee: barnboy → mbarnson
Comment deprecating Apache 1.2 added.

Checking in docs/sgml/installation.sgml;
/cvsroot/mozilla/webtools/bugzilla/docs/sgml/installation.sgml,v  <-- 
new revision: 1.18; previous revision: 1.17

Closed: 22 years ago
Resolution: --- → FIXED
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.