Month: October 2003

  • Comments and Code – Obfuscator 2

    As part of my ongoing online response to some great questions, I offer the following request by Colin Kuskie, webmaster for the Sunset Presbyterian Church:

    Hi Dean,

    My name is Colin Kuskie, and I’m Sunset Presbyterian Church’s
    volunteer webmaster/hostmaster. I’m planning on moving our website,
    www.sunsetpres.org, to a CMS, and I’d like to help secure staff
    and member email addresses against spam by using your obfuscator
    as a macro, but I couldn’t find anywhere to download the code from
    your site.

    Is it publicly available, and if so, could you please give me a
    pointer as to how to find it?

    Thank you,
    Colin

    p.s. Thank you very much for your online minstry. It’s one of
    the things that convinced me to go to a CMS, and then to teach
    myself CSS in order to implement it. I pray that God will you
    your website to enable other churches to reach out with God’s
    message to the world.

    How can I say no to a request like that? So I emailed Colin back with the response “… Colin, stop it, my ego is already ‘well maximized’ enough!” … Actually, that’s not what I said, but I thought it might be fun to share a little opera singer humor with you. Go ahead, ask your minister of music about their well-optimized ego … but I digress …

    Actually, my first response to Colin was “Macro? For what system?.” This wasn’t out of any suspicion, but more out of curiosity, and more out of concern that my original obfuscator hack wouldn’t integrate all that well as it was built into an online form generated using CGI.PM. Colin responded that he intends to integrate the code behind the Mean Dean Anti-Spam E-Mail Obfuscator(MDA-SE-MO) into a macro for a Perl-based content manglement system (CMS) named WebGUI. A robust system I’ve played with once or twice before, but don’t let my ease-of-use fool you. This is one CMS that requires you know Perl, paths and your site map before you go shooting your foot off of with it … but I digress …

    CMS sorties aside, Colin’s question reminded me of this sage advice she’d offer whenever I’d leave the house: “make sure you have on clean underwear.” Not that it would help if the last thing I ever saw was an oncoming cement truck … but I digress …

    So, if I’m going to put my code ‘out there,’ I had better tidy it up a bit, and put it into a easy to deploy, use and maintain Perl module. This way, he could use it for WebGUI, and I could use it for an upcoming MovableType plug-in … unless one of you kind souls comes up with it first … but I digress …

    I also figured if I as going to put it ‘out there,’ I might as well add an option that might really, truly drive spammer’s nutzo … that is to render the hyperlink as inline javascript. Yes, I know 12% of all browsers have Javascript disabled, but then again, how many people using wGet or Curl are actually interested in sending me email? That said, it is for such reasons that I have in the past advocated including a form-based email solution on your church or charity website. All the more so if you’re going to use the inline javascript option on Obfuscator … but perhaps this tangent is better left as a topic for later discussion?

    Anyway, below is the code for the new perl module behind the slightly improved online demonstration of the MDA-SE-MO:


    Yes, this obfuscator isn’t nearly as dastardly as the very cool and very effective online offering from HiveWare (hat tip to Mark Pilgrim) … perhaps by putting the Obfuscator.pm code ‘out there’ … someone will come up with an elegant “<noscript>” solution. I’ve already got one person who’s keen on optimizing the regular expressions … Colin, thank you.

  • A quick look inside my installation bag of tricks

    When a plumber visits your house, they often bring with them a part canvas, part leather bag that weighs in and about 50lbs. I know this because my brother is a plumber, and I’ve had ample opportunity to look inside at all the unusual looking tools he carries with him. I also noticed recently that he’s somewhat particular in how he puts the tools back in … not one can neatly align them in such a bag, but he has three or four well-worn tools he puts in last. This is because these are often the tools he uses first.

    So if you were to look into my virtual ‘what dean uses to install applications’ toolbag, what might you see along the top? Glad you asked: putty, wget,tar, pico, mysql … usually in that order.

    Now I believe I’ve discussed each of these tools (as you can see from the above hyperlinks!-), but don’t think I’ve really ever put it all together to show you what I do to install an application directly onto my web server. Nor do I think I’ve completely explained why I prefer the direct approach.

    On the latter, nothing is more frustrating than downloading a file locally, expanding/uncompressing it, editing various files, FTPing it to your web host, only to find that it doesn’t work due to a file or directory that was either uploaded binary when it should have been uploaded ASCII … or requires an additional step of changing the errant item’s file permissions.

    Instead, I avoid this hassle by using putty to login to my web server, and from the shell, execute some variant of the following commands

    cd $HOME
    wget http://www.foo.org/downloads/foo.tar.gz
    cd $HOME/tmp
    tar -zxvf $HOME/foo.tar.gz
    cd $HOME/www
    mv $HOME/tmp/foo-version2.0.1 foo
    cd foo
    pico config.php
    mysql -uUSERNAME -pPASSWORD mydbNAME < foo.sql

    Now of course, each installation is going to be a little different, for example, you can see that I throw mkdir and chmod into the mix in a past article I wrote entitled “Moving MovableType.

    That said (and finally to the ‘former’) the above boilerplate also provides some other unseen advantages. First, you don’t have to have to download the file locally. This is good because it also means you don’t kill bandwidth FTPing each file. This is good because you don’t have to worry about uploading the file in the wrong mode … and you install the files using the permissions defined by the developer.

    As always, your mileage may vary … especially in those one or two cases where the individual making the .tar.gz file doesn’t put stuff into it’s own directory … which explains why I put everything in $HOME/tmp first …