Archive for October, 2003
I’m halfway through integrating users - that is, the ability to log in and the restriction of certain features to certain users or classes of users. Really, I’m halfway through the logging-in part, and the rest will add yet more complexity (of course). And I am watching myself make my software worse.
Little compromises. Sure, I could work out how to let people put quote marks in page titles without breaking stuff, but it’s so much damned trouble. Now there might be issues with ampersands too. Maybe this will all get worked out over time, and I’m worrying for nothing (what, me?). Or maybe Alan Cooper was right, and writing the code for your own spec is a hopeless conflict of interest. Unless you’re that rare programmer of surpassing dedication and professionalism.
Which I’m not. Mediocrity ahoy!
(Note: The recent-comments RSS feed is indeed a much better way to handle things than the one-feed-per-post approach I was trying. I had to install a plugin to get it to work, but by virtue of the fact that you’re reading this, it’s clear that I’ve got nothing else to bloody well do with my life. The feeds for each post will continue to exist, but as you can see, I’m not linking to them anymore. Ha!)
October 22nd, 2003
It’s looking like PhpWiki has matured technically a whole damn lot. It has WikiPlugins, which can probably be made to act like my envisioned pagetypes. They could even be more flexible than pagetypes, but, accordingly, harder to control. It also has SubPages, which is just a simple hierarchy mechanism - combine that with some key plugins and you can basically hack up something that looks a lot like Everything2. (Aping E2 isn’t the goal of the Wicker project, but it’s one useful benchmark - if we can do all that, we can probably do a lot of other, more interesting stuff too.)
So I’m tempted to drop Wicker and start hacking on PhpWiki instead. But the trouble with this comes down to implementation, as it always seems to do in Wikiland. It’s always difficult to understand other people’s code. My objections come down to interface, mostly - the specific way PhpWiki lets people into all this functionality just feels sort of wrong to me. And, as I sort of covered earlier, that seems to be why there are so many Wiki codebases. Some developer says, “that’s not the way I’d do it,” and soon there are n + 1 Wikis, where n = too damn many. I’m self-conscious about contributing to this problem.
So, as my paranoia increases about little problems in my code - security, inflexibility et alia - the temptation to cut bait and hack on something else increases. With that action would die the already-unhealthy dream of making some money off this software. I really just want my mammoth wiki-weblog-E2-like playground…
(Side note: RSS feeds for comments on individual posts really suck compared to MT’s built-in Recent Comments for an entire blog, which can be RSSed just as simply. I’ll correct this, uh, sometime.)
October 11th, 2003
I’ve had to make a rather fraught decision. Others have made it too, and they don’t talk about it, maybe because it has to do with security. But from what I can see, if your code is open in any way, it isn’t hidden information, and the alternatives are not always any more secure
If you want to do the thing where you send people their password if they forget it, you have to store people’s passwords as cleartext in the database. There may be some fancier way to do it than that, involving some wacky connection to a machine or file that isn’t otherwise accessible, but basically, if we’re aiming for this thing to be runnable on shared hosting (which we are), I have a feeling that passwords will be in the DB, and they’ll have to be clear. The forgot-your-password deal can be worked a few different ways: store an answer to a stock challenge question, store a challenge question and its answer, require the user to enter a username-and-email pair, or just ask for an email and see if a username is associated with it, or (finally) just ask for a username and kick an email out to the associated address, with the password in it. (That last bit is the eventual goal of ll these methods, of course; the theory is, only the real user gets the email with the password in it, in any case.)
Those are all the methods I’ve seen. There are probably others. They all rely on the security of cleartext email, of the server running the scripts, and of the server running the database. None of those are necessarily secure, but none of them are my problem as the author of the scripts. And this is all to say nothing of our repeated sending of cleartext passwords and session hashes in the cookie.
What I’m going on about, what’s bugging me, is that authors of web applications seem to make a lot of lax assumptions about security. I have no problem with that; I am too. But it bugs me anyway, because past a certain point, there seems to be nothing you can really do.
October 2nd, 2003