Having overcome some settings that can't be changed at runtime, and dealt with some that can and helped users help themselves while installing KnowledgeTree, I realise that I could make almost all the changes as easy as, at most, enabling a web server option, using .htaccess files.

So, let's start with the easy stuff, making the file:

php_value default_mimetype text/html
php_value auto_prepend_file none
php_value auto_append_file none
php_flag display_startup_errors ON
php_flag display_errors ON
php_flag file_uploads ON
php_flag magic_quotes_gpc OFF
php_flag magic_quotes_runtime OFF
php_flag register_globals OFF
php_flag output_buffering OFF
php_flag session.auto_start OFF
php_value upload_max_filesize 16M
php_value post_max_size 16M
php_value memory_limit 16M
php_value max_input_time -1
php_value max_execution_time 60

Ok, shove that in your web root, and you're sorted, right?

Well, firstly, it may just not be read by the web server. On Ubuntu, it's the default to read it. On our production server at work, SUSE, it defaults to not doing so.

The other issue is that Apache gives wonderful errors if you put something in a .htaccess file that it doesn't like. Like a statement it doesn't know, or that you can't change. I've set my aim to help even people who haven't got PHP installed. If they don't have PHP installed, they'll get Internal Server Error, and give up, or even worse, complain to the developers.

So, just surround the commands with a condition of the module being loaded:


...

Might as well add some standard Apache options while we're there, to make sure some other weirdness doesn't come into our web root:

LimitRequestBody 0
DirectoryIndex index.html index.php
Options none

Options none is the start of making sure that any uploads don't suddenly mean you're executing code, if you've gone against the explicit instructions in the documentation and left the Documents directory within the web root.

LimitRequestBody 0 and the various maximums are an attempt to lower the number of complaints about upload problems. On Fedora Core, for example, LimitRequestBody is set to a really low number, so uploads are limited. This is an Apache setting, not a PHP one, so it tends to confuse people, and that makes them blame the poor developer.

In our pre-configuration checkup, it'd be great, even if everything were set up, to know if our .htaccess file worked. It seems you can't just use php_flag or php_value on a custom configuration item, and have ini_get() pick it up. But, we can use Apache's SetEnv statement to set an environment variable:


SetEnv kt_htaccess_worked yes

Then, in my pre-configuration checkup, I can test for it:

So, since we're most likely going to have .htaccess working, we can put .htaccess files in some directories to prevent access via the web. Obviously the documents are the most important thing to protect from direct we access, but the log and (less likely) configuration directories may conceivably give something away. This is pretty trivial:

Order deny,allow
Deny from all

But .htaccess files are used, we now have the possibility of users uploading .htaccess files in the documents directory to override our settings. Maybe I'm just being paranoid, since most KnowledgeTree installations only have trusted users. But fixing this is relatively easy in our .htaccess file in the documents directory:

Order deny,allow
Deny from all
AllowOverride none

The final line ensures that any .htaccess files under that one aren't considered.

Ok, what happens if our .htaccess file isn't read, and the user ignores the instruction to move their documents directory. We'd like to test this in our checkup accurately, without giving a false-positive or false-negative response. The only way to do that is to actually check via HTTP:

$linkcheck = generateLink('/Documents/', '');
$handle = @fopen($linkcheck, 'rb');
if ($handle !== false) {
    print '
Your document directory seems to
    be accessible via the web!
';
}

So, if you haven't done your work as a user, you get this in the checkup:

Next, I'm going to be developing through-the-web utilities to create the initial database.