[libdb-develop] LibDB 0.0.2 Released

[Morbus I. <mo...@di...>]

Download: http://osdn.dl.sf.net/sourceforge/libdb/libdb-0.0.2.tar.gz
Blog Entry: http://www.disobey.com/dnn/2004/02/index.shtml#001576
Release Notes: http://www.disobey.com/noos/LibDB/?ReleaseNotes002
LibDB Homepage: http://www.disobey.com/noos/LibDB/

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!

-- 
Morbus Iff ( don't heckle the super-villian )
Technical: http://www.oreillynet.com/pub/au/779
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus