Wikka Documentation : HtaccessConfigInfo

HomePage :: Index :: RecentChanges :: Search :: Login/Register
Wikka Documentation

.htaccess Configuration Documentation

applies to Wikka 1.1.6.0 (and 1.1.5.1 and 1.1.53)

See also:
This is the documentation page for how Wikka manages server configuration via .htaccess files. This applies only to Wikka installed on an Apache webserver.
 

Each documented directive (or group of directives) 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.
Note that the AllowOverride directives mentioned must be located in a <Directory> section for the directory Wikka is installed in or a higher one.


Wikka on Apache
Wikka "assumes" it will be installed on an Apache web server. Although it's perfectly possible to install Wikka on other web servers (as long as PHP is installed), Wikka comes with a number of .htaccess configuration files for use with Apache. This page serves as an explanation of the function of these files and how they work.
If you control your own server and are able to use the httpd.conf file for server configuration, using this is preferable over using .htaccess files. This page does not explain how to do that but if you have sufficient Apache knowledge you can use this page as a guideline for what to add to your configuration to achieve the same functionality.

Wikka on other web servers
With other web servers than Apache these files will generally be ignored: to implement their function you'll have to do your own configuration. The documentation on this page can serve as a guideline but we cannot directly help you configure Wikka for another web server.
Users running Wikka on other webservers than Apache are welcome to add documentation for that to this page or on a separate page on this site!

What is an .htaccess file?


The Apache web server is normally configured by means of a file called httpd.conf; this file can contain configuration directives for the server in general, as well as for specific directories and files. If you have installed your website (or Wikka) on a hosted server, you generally do not have access to your own httpd.conf file. A web host may allow their customers some configuration for their own sites though by enabling the use of .htaccess files in their own directories; many don't though. Not every kind of server configuration can be done via .htaccess - but a number of very useful things can, and Wikka tries to take advantage of that. For instance, you can use it for some security, and to enable "pretty" (and more search-engine-friendly) URLs.

Wikka installs a number of .htaccess files. These will be effective only if:
  1. Wikka is installed on an Apache server
  2. The server is configured to allow the use of .htaccess files for the directives we use here. (If not, you may try convincing your host to allow it for you, armed with the documentation on this page to convince them why it's important. See the 'Prerequisite' boxes for what is needed in the main Apache configuration.)

The .htaccess files distributed with Wikka


As of version 1.1.6.0 Wikka installs the following .htaccess files:

In the installation directory:
### STOP REFERRER SPAM
SetEnvIfNoCase Referer ".*(adultsite|picturesplace|learnthebiz|pi-o|erotica|ghettoinc|port5|bulk-email|camgirls|paris-hilton|modelos|kredit|handyflirt24|versicherung|wwww|erotower|krank|x-1000|flirtnet|blowjob|agedwife|in-the-vip|boysfirsttime|milf|captain-stabbin|tranny|Kontakt|erotik|fetish|frauen|hardcore|fick|krankenversicherung|jinnan-cross|8thstreet|xxx|XXX|ficken|fuck).*" BadReferrer

order deny,allow
deny from env=BadReferrer

<IfModule mod_rewrite.c>
 RewriteEngine on
 RewriteCond %{REQUEST_FILENAME} -d
 RewriteRule ^(.*/[^\./]*[^/])$ $1/
 RewriteRule ^(.*)$ wikka.php?wakka=$1 [QSA,L]
</IfModule>

Version 1.1.5.1 and 1.1.5.3 had the same .htaccess file.

In a number of subdirectories (where [wikka] stands for the Wikka installation directory):
These all have the same content:
<IfModule mod_rewrite.c>
RewriteEngine off
</IfModule>

Version 1.1.5.1 and 1.1.5.3 do not have a 3rdparty directory; the corresponding .htaccess files are found in [wikka]/freemind/ and [wikka]/wikiedit2/.

The main .htaccess file


The file provides two main functions:

Combating referrer spam


This is handled by the following directives (local line numbers added for easy reference):
  1. SetEnvIfNoCase Referer ".*(adultsite|picturesplace|learnthebiz|pi-o|erotica|ghettoinc|port5|bulk-email|camgirls|paris-hilton|modelos|kredit|handyflirt24|versicherung|wwww|erotower|krank|x-1000|flirtnet|blowjob|agedwife|in-the-vip|boysfirsttime|milf|captain-stabbin|tranny|Kontakt|erotik|fetish|frauen|hardcore|fick|krankenversicherung|jinnan-cross|8thstreet|xxx|XXX|ficken|fuck).*" BadReferrer
  2. order deny,allow
  3. deny from env=BadReferrer


Prerequisite:
When a browser (or other user agent) makes a server request, it may send along a "referrer" in a HTTP header; normally this indicates the page where a link to the requested page was found. Spammers can fake the referrer hoping that a referrer list on the site will provide a link back to the (fake) referrer URL.


Do note that sending a '403' response will not prevent the referrer spam turning up in the server logs (if it is repeated); it merely prevents it from showing up in the referrers that Wikka logs since they won't make it that far.

To make effective use of this mechanism, you should regularly check the referrers to your site, and use this to update the substrings list between brackets. The current list is rather old, and bound to be not very effective any more: it will help only if it is kept up-to-date with actual (undesirable) referrers you find on your Wikka site. Note that the substrings need only be in lowercase since the matching is case-insensitive (thus having both 'xxx' and 'XXX' is superfluous)!

Friendly URLs


Prerequisite:
In addition the mod_rewrite extension module must be installed and enabled.
For "Friendly URLs" Wikka makes use of the mod_rewrite module of Apache that rewrites requested URLs on the fly. This is an extension module, meaning that it needs to be explicitly enabled in the main Apache configuration. If you control your Apache configuration, make sure it is enabled. If you don't (as on most hosted accounts), ask your host if mod_rewrite is enabled.
Currently there is no known method to simply detect directly whether mod_rewrite is available.
Of course configuration via .htaccess files needs to be enabled as well for Wikka to be able to use mod_rewrite configured in the main .htaccess file.

Wikka needs to know you want to use URL rewriting
See ModRewrite for how to tell Wikka whether it should assume URL rewriting.

Apache should not execute what it doesn't support
Since the directives used by mod_rewrite will result in a '500 server error' when mod_rewrite is not enabled, the statements are enclosed in an IfModule section so Apache will only try to to execute them when mod_rewrite is enabled:
<IfModule mod_rewrite.c>
 #...rewrite statements go here
</IfModule>


Turning on the engine
The block starts with actually turning the rewrite engine on:
RewriteEngine on

In some cases, the rewrite engine may already be turned on in the main Apache configuration. You cannot turn it on again: Apache will generate a 500 server error in this case. If you get this error, try disabling this one statement by commenting it out (put a # in front of it). See also ServerErrorWorkaround.

Handling directories
The first step is to ensure that directories have a URL that actually ends in a slash (required for directories):
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^(.*/[^\./]*[^/])$ $1/

Let's see what it does:
The result of this is that the browser will receive a "301 moved permanently" response from the server, with a Location: header to tell it where to look - the result of the rewrite rule. The browser will then (have to) make a new request for the directory, this time with the slash added at the end.

If you're thinking this has nothing to do with "friendly URLs" you're right. :) But it's there so it gets documented here...
There are actually several problems with this part of the current .htaccess file as distributed with Wikka 1.1.6.0 (and earlier); see the development page for more about this.

Friendly URLs (at last)
Here's the beef, just one, but one really important, statement:
RewriteRule ^(.*)$ wikka.php?wakka=$1 [QSA,L]

Here it's important to know that before Apache starts working with a URL in mod_rewrite it strips off any query string (the part that starts with a ?) and remembers it for later use. The regular expression we use here simply matches the whole string (again - within the directory where the .htaccess is sitting) and then appends it ($1) to wikka.php?wakka= which is the format that Wikak needs internally. What if there was a query string already? We tell Apache to append it again with the QSA flag (Query String Append) and Apache is clever enough not to use a question mark if there is already one in the resulting URL. Finally, we tell Apache that this is the last rule to apply by means of the L flag.

The .htaccess files in the subdirectories


When a browser renders a page, it will first request the URL for the page from the server, and then does an additional request for any files that are embedded or needed for rendering such as images, stylesheets, JavaScript files and applets. But because we are rewriting the URLs the browser requests for these extra resources will also get treated by the rewrite engine.

Prerequisite:
In addition the mod_rewrite extension module must be installed and enabled.
If we don't prevent this from happening, the rewriting will result in URLs that no longer point to the actual files (when they did in the first place). We must tell Apache to not use URL rewriting for these files. This is easy, since they are in separate directories: the .htaccess file placed in these directories simply tells Apache to turn off the rewriting engine here:
RewriteEngine off

(again wrapped in an appropriate IfModule section so that the statement will be executed only if the mod_rewrite module is actually enabled). URLs pointing to files in these directories now won't be rewritten.


CategoryDocumentation
There are no comments on this page.
Creative Common Attribution-ShareAlike License
Valid XHTML 1.0 Transitional :: Valid CSS :: Powered by WikkaWiki
Page was generated in 0.0273 seconds