Sluggish

The lack of daylight (and the fact I sleep through much of it) might explain why I’ve been feeling a little sluggish these last few days. Even if I sleep 8+ hours, I have to coax myself out of bed. I have a lot to do in the coming days, and just thinking about them makes me feel tired. One of those things is a meeting on Tuesday morning that I anticipate will be difficult. Some people’s nose unexpectedly got out of joint and, while I don’t want to make matters worse, I also don’t want “nasal disjunction” to get in the way of progress.

Aside from the things I have to do, I’ll be driving up to Moncton on Friday, weather permitting. At this time of year, it’s always “weather permitting.” My mother will be spending Christmas in Ottawa, so my brothers and I want to have a mini pre-Xmas thingy with her before she leaves on the 21st.

Excuse me while I yawn… All I’m saying is that I’d just as soon sleep 12 hours a day and do very little the other 12 hours. Winter has that effect of me.

Exceptional or Not

There’s been this on-going thread in my Web host’s discussion forum about how some PHP-based scripts to generate mail-in forms can be vulnerable to hijacking by spammers. Because my CMS offers ways of plunking a mail-in contact form, I’ve been paying close attention to this thread to see if my forms are vulnerable as well. I mean, if they are, I would certainly want to fix them.

But as far as I can figure out, they’re not. I make the CMS run the data entered in the fields through so many checks before passing it to the mail function that I haven’t been able to replicate the exploits others have experienced. Also, the field names on the forms aren’t standard, but if one day my CMS gets widely used, I’m sure some script kiddie would study the form to come up with a way to reference the fields by name. So, while I feel that I’ve built so many checks to render exploits very difficult, I’m not assuming someone couldn’t succeed one day at thwarting my efforts. Therefore, I keep posted on other people’s woes in case they apply to my CMS.

For instance, my Web host has uncovered a problem with PHP-based mail-in scripts whose destination address is AOL. Because of the mail headers PHP automatically generates, legitimate messages to an AOL address sent from such a PHP form are likely to be rejected by AOL servers, and there doesn’t seem to be much hope for a happy resolution of this problem soon (if ever). So I’ll have to give some thought to whether or not I should get my CMS to issue a warning (on both the admin and public sides) about how AOL addresses aren’t viable. Doing so might make sense if the situation is permanent, but what if AOL changes its policy or Web hosts, including my own, find a workaround one day? Adding a warning wouldn’t take me that long, but then I’d have to remember to check regularly to see if the situation changed favorably. But with the looming widespread implementation of PHP5 and the adjustments that change might necessitate with scripts built with PHP4, keeping on top of AOL’s own quirky policies would just be another thing to bear in mind along with what I consider more important and critical technical developments.

A Web developer’s job is never done.