LibDB 0.0.2 Released

A day later, and a new release of the installer code. I've fixed four bugs, as well as pondered ways of improving *before the install*. First, the settings file ".htlibdb", which stores the database username and password. Obviously, it's important to make this file well-protected; we certainly don't want give free access to the user's database.

The ".ht" part gives the file special meaning to Apache, the most popular web server. When a file starts with ".ht", it is never served to the general public, protected by a filter that stops outside access. Two problems. First, I'm assuming the user is running Apache. Other webservers might not treat ".ht" in the same way, canceling all implied security.

The other downside of ".htlibdb" affects end-usability. A file that starts with a dot is "hidden" from normal viewing. Similarly, most FTP clients hide them in file listings. If the LibDB installer can't change that file's permissions, it instructs the user to. If the user *can't see* the invisible file, more support emails for me, sure, but more people *who just give up*, never asking for help. Too much effort, and you know what? It is.

I'm a few inches away from renaming ".htlibdb" to "settings.cgi", which follows the same behavior as Movable Type. In most cases, webservers are configured to treat .cgi files as executables, running them as opposed to simply showing their contents. Since the file is not code, it'd "short circuit" and display an "Internal Server Error". For configurations where .cgi is not executable, our installer can attempt to fix the permissions, prompting the user otherwise. There are more chances for .cgi scripts to break and leak data, but there are also more chances for a user to actually finish the install instead of throwing their hands-up in "where is it?" frustation.

The second big problem with the installer is location: installer/index.cgi. There's also a file called /index.cgi and, in early tests, two people mistook one file for the other, either in permission changing or in accessing through the browser. I'm thinking a better solution would be /installer.cgi: no more accidental duplicity, a single location for executable files, and a more understandable URL.

Download, test, comment, improve. Thank you!