Posts filed under 'Implementation'
I had a look at my referrer logs to see if anyone is really reading this… it’s hard to tell, all those hits could just be coming from my aggregator. I understand that some folks were trying to add something absurd to the Atom spec so they could prevent such problems and actually know who was reading their feeds. I’m gonna take the direct approach: if you’re reading, post a comment!
Anyway, the OO version of Wicker is now under private testing. Viewing pages works fine, and so (amazingly) does subclassing the basic Page class to do SoftlinkPages. The SoftlinkPage class isn’t perfect yet - I’ve decided to have them put “lastpage=XX” codes into URLs, instead of trying to read the referrer and parse out the page that called it. That will limit the creation of softlinks to only occur when you’re coming from another SoftlinkPage, but hey. It doesn’t have to be perfect.
What I’m working on now is a bug with logging in. It likes to forget who you are, instantly, between page loads, so something about the way the User class (which I’ve actually been using a while now, so I know it basically works) is getting toted around in the session has gotten borked. I hope this does not turn into another months-long stallout.
Once I have that worked out, I can go to work on seriously debugging Edit functionality. When the current feature set is fairly bug-free, I’m going to set about opening up the code under the GPL, likely on SourceForge unless they prove to be too hard to deal with compared to the competition.
I am surprisingly lucid for having had no protein today. (Watch, now that I’ve typed this I’ll start having dizzy spells.)
[Later that day: editing works! In fact, editing works better.]
May 7th, 2004
I finally unborked WickerTest so that SoftlinkPages no longer uniformly result in mysql urps. (Yes, I’m pretty sure that sentence was English.) I suspect I broke softlinks in the process, but at least you can do those nice things like reading and editing.
I’ve been looking around at alternative Wiki engines lately, because I always am, and learning from Tiki as well as from WTF, the appealingly contrived acronym (Wiki Type Framework) for a project that aimed to do something similar to what I’m doing with Wicker. Only different enough to be totally perplexing, and the project’s been dead for two years anyway, but yeah.
What I am saying, and what you are caring about oh yes you are, is that I’m going to retool Wicker’s innards to be all object-oriented and stuff. That way, one can create a new type of page by inheriting the qualities of another type and building on them. That will solve my current problem of having to have explicit hooks everywhere for everything a pagetype might want to do, which is unbelievably janky, whilst still keeping a pagetype’s code self-contained and neat. I know I am not using the word “whilst” properly.
As a consequence of this move, I will be using ops. URLs will have things like “op=edit” and “op=view” in them. This will make our URLs remind people of E2 that much more, which is kind of a mixed thing, but hey. Pagetypes will have but to override the function (on their parent pagetype) that corresponds to the op, to do something different. And a lot of other neat stuff.
This is one of those things where everything gets easier in the long run, but in the short run I have to rip everything to shreds and start again. So, who knows when I’ll be done, and in the meantime, let’s play Lexicon.
April 29th, 2004
So: Wicker’s up, friends are signing up for accounts although mysteriously not goofing around and editing things, life is lovely. I decided to start writing Wicker’s first pagetype: a page with E2-style softlinks. From the very first draft of the very first script I wrote for Wicker, pagetypes were intended to be quite straightforward: if you see that a page has a type, include a script named after that type just before you display the page.
Obviously, I was destined, in the very first pagetype I wrote, to discover that I needed to touch more code than that. That, in fact, I needed to touch several scripts with special-cased code, just to do something incredibly simple.
I am so very, very lame compared to real coders.
But it’s okay, because really, the whole goal with Wicker right now is “make it work.” Not make it work fast, not make it work well, not even make it maintainable. Make it work, then consider it a prototype.
Then, once somebody who can actually code thinks Wicker might be good for something, I make them do the hard work! Yay!
March 26th, 2004
Because I’m dumb, I am thinking about pushing the panic button, and rewriting Wicker from the ground up in Python. Pretty much all of what I need is there: basic CGI crap, templating, database access, maybe even some user-management libraries that don’t suck. I am considering this move because Bob Galloway, known to all three people who experienced my brief flirtation with ecore as the Funk Queen of the Universe, is an experienced wikismith and ardent Python advocate. I could really use his help. Also, I have tried everything I can think of to eliminate the damned login bug and it is starting to look easier to just start the hell over. Thoughts?
January 15th, 2004
What do you think: should I just set the logins to always remember you, until such time as I fix the bugs with the temporary cookie? Or will that just make me put the temporary cookie bug on the back burner and forget about it?
December 24th, 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
Next Posts