=====Configuration via .htaccess=====
>>==See also:==
Documentation: HtaccessConfigInfo.>>This is the development page for the .htaccess files (to be) distributed with Wikka.::c::
For documentation of what the current .htaccess files do, see HtaccessConfigInfo; here, we're going to look at what the main .htaccess file //might// do for us - while also getting rid of the separate .htaccess files in subdirectories.
''Each item has a "Prerequisite" box: this specifies what is required in Apache's main configuration (##httpd.conf##) for the current or higher directory to enable the proposed directive(s) in the .htaccess file. Multiple bulleted items (list) imply 'or': **one** of these must be specified to enable the directive in an ##.htaccess## file.''
This page assumes we're working on Apache; other web servers may have similar mechanisms to exploit (even may use .htaccess files for that) but we're not dealing with that here.
//Users working with a different webserver are welcome to add their own equivalent methods to this page or a separate one for their webserver!//
''//This page is still unfinished; sections where more content will be added are indicated as such.//''
====Efficiency====
===Default Apache behavior===
Normally an Apache server has a ##""DirectoryIndex""## directive in its server configuration (##httpd.conf##) that tells it which "index" file(s) to look for, in what order, when a user agent makes a request for a directory. Each of the file names specified will be tried in turn; if none of them is found (or none are defined), the directory content will be shown (if enabled) or a '403 Forbidden' response will be given if directory browsing is disabled //(see **Security options** below)//.
==Getting to Wikka's main file: ##wikka.php##==
Wikka runs operates completely through ##wikka.php##, and it comes with an ##index.php## file in its installation directory which does nothing but redirect to ##wikka.php## - which in its turn will redirect to the declared home page if not given a page parameter. The problem with this method is that it assumes that Apache's configured search path actually contains not just the standard ##index.html## but also ##index.php## - not guaranteed to be the case! But even if it is, going first to ##index.php## only to be redirected to ##wikka.php## is rather ineffcient, because it means **three** browser requests just to get at the home page when it's requesting the installation directory.
===Making it more efficient===
>>Prerequisite:
~-##""AllowOverride"" Indexes##
~-##""AllowOverride"" All##
>>If ##.htaccess## is not enabled on the server, we'll still need that ##index.php## page redirecting to ##wikka.php## (and hope it is declared in the Apache configuration as one of the directory index files to look for) - so we'll have to keep it. But if it //is// enabled we can save one browser roundtrip by telling Apache to go looking directly for ##wikka.php## when a directory is requested - instead of going through its declared search path until it stumbles onto ##index.html## which does exist in the directory. This will do it:
%%(apache)DirectoryIndex wikka.php%%
====Security options====
===Combating referrer spam===
>>Prerequisite:
~-##""AllowOverride FileInfo Limit""##
~-##""AllowOverride All""##>>The default Wikka ##.htaccess## file has something like this (blank line removed and capitalization adapted to conform to the norm):::c::
%%(apache)SetEnvIfNoCase Referer ".*(...|...|...).*" BadReferrer
Order Deny,Allow
Deny from env=BadReferrer
%%
The ##(...|...|...)## part here represents where the substrings to match referrer URLs with would go (separated by pipe characters).
In principle, this will work to stop some URLs from re-appearing in the referrers list (which isn't indexed anyway). But the problem with the current expression (see HtaccessConfigInfo) is that it is old, and probably does not reflect current referrer spam "habits".
So I propose we keep this (syntax rewritten as above) but we should revise the list of substrings, using our own referer blacklist here as a guideline. Looking at that, I notice two major themes: porn and erotica, and online pharmacies (not surprisingly). Some care should be taken with the actual list of substrings, though. For instance (I'm just making this up) there might be a quite legitimate "gay pride wiki" using Wikka; if such a site exist, it //would// cause quite legitimate referrer entries because it actually links back to our site. Which indicates we should avoid using a generic terms (like 'gay') but look for keywords that suggest porn (or online pharmacies, etc.) instead.
A new list consisting of medicine names and some 'porn' indicators would probably be more effective than what we have now. But most important is to take care that the list would not deny access to sites **actually** linking to a Wikka site.
~&As a note, the current format of the regular expression can potentially cause valid pages to fail. For example if you have ##.*(rape|porn).*## as the filter, you will be unable to edit valid wiki pages like Ope//raPe//rformances or To//pOrn//amentation. A work around is to use \b instead of .* — IanAndolina
~~&Quite right - and it's better to miss stopping some referrers than to stop legitimate referrers. So our more conservative expression would become %%\b(...|...|...)\b%% ---While that would miss 'pornography' it would still catch many of the referers we now have in our referrer blacklist. --JavaWoman
===Preventing directories from being browsed===
//see also **Directory requests** below!//
We have a nice files action that makes it possible (at least for admins) to upload files and for visitors to download them. Using the files action on a page gives people access to one or all of the files "attached" to that page - and if there is no files action on the page, the attached files are hidden.
But are they? It really depends on the main Apache configuration. On many systems, directory browsing is permitted, which means that when one requests a directory and there is no index file found in that directory, Apache will construct a page which gives access to the (non-hidden) files in that directory. So if Apache is not configured to prevent this, all files will actually be accessible for anyone with a little bit of knowledge of the Wikka directory structure. The same goes for other directories - in fact all that do not have an index file that Apache recognizes.
Generally it's a good idea not to allow access to files via directory browsing (unless you specifically want to give "FTP-like" access to them). We can do this easily via the .htaccess file as well - regardless of what Apache's main setting is.
==Method 1: hiding the files==
>>Prerequisite:
~-##""AllowOverride Indexes""##
~-##""AllowOverride All""##>>The first possible approach is to tell Apache to "ignore" the files you don't want to be visible. You can do that by extension, or simply tell it ito ignore "all" by using a '*' wildcard:::c::
%%(apache)IndexIgnore *%%
~-Pro: the visitor gets an index page that doesn't contain any files
~-Con: confusing if the visitor already **knows** there must be files in the directory requested
==Method 2: denying access==
>>Prerequisite:
~-##""AllowOverride Indexes""##
~-##""AllowOverride All""##>>Another possibility is to simply make it **impossible** to access a directory. This can be done with another directive:::c::
%%(apache)Options -Indexes%%
~-Pro: the visitor won't be confused by an "empty" list of files
~-Con: the result is actually a '403 Forbidden' server response which by itself is not very friendly.
>>Prerequisite:
~-##""AllowOverride FileInfo""##
~-##""AllowOverride All""##>>The unfriendly '403' response could be handled by adding a custom error page - or better simply using that mechanism to redirect right back to the homepage:::c::
%%(apache)ErrorDocument 403 /wikka.php%%
''If Wikka is not installed in the root but in a subdirectory, the path here should reflect the true location of the ##wikka.php## file, of course.''
====Directory requests====
The current main .htaccess file makes use of **##mod_rewrite##** to ensure directory requests actually end in a slash (as is required); the following code is used:
%%(apache;7)
If your browser doesn't automatically redirect, follow this link to take you to the home page
%% Note that we don't make any assumptions about the name of the Wikka site; of course a WikiAdmin can edit the file to reflect the name but we can't do it dynamically: this is a static HTML file. ''It's entirely possible that the (root) directory where Wikka is installed already contains an ##index.html## file. To prevent blindly overwriting that file, our file should not come as a physical file in the installation archive, but be **generated dynamically** from the installer program. The installer can detect the pre-existence of an ##index.html## file and ask the WikiAdmin permission for overwriting it (and renaming the original as a backup!). And when we are **generating** the file from the installer, we can also insert the name of the Wikka site, giving a warning to the WikiAdmin that this file must be edited if the name is changed in the configuration at some point. //(A future user interface for maintaining the configuration could do this automatically, of course.)//'' //more later// ---- ==External sites== ~-[[http://apache-server.com/tutorials/ATusing-htaccess.html | Using .htaccess Files with Apache]] ~-[[http://httpd.apache.org/docs-2.0/howto/htaccess.html | Apache Tutorial: .htaccess files]] ---- CategoryDevelopmentArchitecture