Stopping Adobe flash upgrade from launching a browser tab has interesting side effect - Can no longer click on links in emails

After updating adobe recently, I was annoyed when it launched a browser tab to inform me that, yes, the update had succeeded. Of course, programs use this tactic these days to get around the common habit of otherwise blocking this renegade attempts to "phone home". But... it's quite problematic to stop a program launching a tab in your browser.
So after some web searching and seeing a few tales from others trying to achieve the same thing, I was eventually drawn to a comment by a user who said;

You're making it too complicated - just set the default browser to a browser you don't use and block that.

Interesting angle, but still problematic if you don't have sufficient firewall control. On my mac, I could turn on the built-in firewall, but that's really only about blocking inbound connections. I've used ipfw before, and it's great for what it does, but it doesn't do application specific blocks the way that most firewall applications on Windows can. And I didn't want to foray into the world of custom firewalls for mac - I find they often promise a lot, but deliver little, and gave up on them long ago.
So what to do?
One suggestion was to install a little used browser and then move the exe preventing execution. Not bad, but oh so much fiddling just for a simple task.
I poked about the Safari settings anyway and suddenly realised I could set the default browser to any application I like. I tried setting it to MacVim, which was fun when MacVim complained about not understanding the protocol. Nearly, but too messy.
So I tried setting it to TextEdit. Bingo! Now we were cooking.
I gave it a test run:

• "run http://www.google.com" --- fires up TextEdit but doesn't actually do anything else
• "run some_file.html" --- contents of some_file.html end up in TextEdit

I could live with that. Let's see Adobe flash upgrade launch it's little phone-home browser tab now!
As a bonus (depending on how you look at it), I stumbled a little today when I couldn't open a link in an email. I scratched my head for a little while until I finally remembered that I'd disabled that baby!. Oh, I'll just cut and paste. How about that - I can't click links in emails. Maybe I should set it up this way on my family and friends machines too! :)

Getting admin access to mac with knowing the current password

Worth repeating

Change the password in single user mode

1. Hold ⌘S on startup
2. mount -uw / (fsck -fy is not needed)
3. launchctl load /System/Library/LaunchDaemons/com.apple.opendirectoryd.plist (or /System/Library/LaunchDaemons/com.apple.DirectoryServices.plist in 10.6)
4. dscl . passwd /Users/username (without a trailing slash) and enter a new password. You can ignore the error about com.apple.DirectoryServices.plist.
5. reboot

Create a new admin account

1. Hold ⌘S on startup
2. mount -uw / (fsck -fy is not needed)
3. rm /var/db/.AppleSetupDone
4. reboot
5. Go through the steps of creating a new account. You can leave all fields in the personal information step blank
6. After logging in on the new account, go to the Users & Groups preference pane
7. Select the old account, press the Reset Password... button, and enter a new password

Restart and enter Recovery mode (for 10.7 Lion and newer OS only)

1. Hold ⌘R on startup
2. Open Terminal from the Utilities menu
3. Type resetpassword and follow the instructions

Management

Any network systems management setup that dumps so much raw data on administrators that they need big-data analytics to sift through it for answers is fundamentally flawed - Shmuel Kliger

Mis-coding SQLite/PHP leads to silent failure

Damn rookie errors! I spent over an hour last night trying to work out why my database code suddenly and mysteriously stopped working. It was compounded by the fact that I checked in a change and around the same time patched and rebooted my machine and mistakenly assumed that it was the latter and and not my dud code that was causing the problem!

function create() {
   $stmt = "CREATE TABLE if not exists Worklog(".
      "Id integer PRIMARY KEY, ".
      "Lastmod TIMESTAMP NOT NULL DEFAULT (strftime('%s', 'now')), ".
      "Start TIMESTAMP, ".
      "End TIMESTAMP, ".
      "Ticket text, ".
      "Desc text, ".
      "Cat1 text, ".
      "Cat2 text)";
   if (! $this->dbh->query($stmt)) {
      die("Cannot create table '$stmt': $error");
   }
   $stmt = "BEGIN TRANSACTION; ".
      "CREATE TRIGGER insert_worklog_lastmod ".
      "After update on Worklog begin update Worklog ".
      "set Lastmod = strftime('%s','now') where rowid=new.rowid; end; ".
      "COMMIT;";
   if (! $this->dbh->query($stmt)) {
      die("Cannot create trigger '$stmt': $error");
   }
}

(some lines edited/removed to simplify display)

So, in retrospect, yes I made a fine lot of errors for such a small snippet of code. But the major one, the show-stopper that was causing my CRUD to fail silently? Acting the real rookie, I tried to shove more than one statement into a query statement. In retrospect, it's pretty bloody obvious that the BEGIN TRANSACTION (which was only there I might add, because I lazily copied this trigger creation from another source) was going to be the only section of that statement applied. With the actual trigger creation and - most importantly - the COMMIT being rightly ignored.

Any wonder my application stopped writing: the whole damn thing was sitting on a TRANSACTION request that never completed.

So what other mistakes did I manage to fit in?

• Use of query rather than exec to execute a result-less query
• Constantly attempting to create the trigger (not protected by if not exists)

Hashing a password

If you're going to hash a password then you may as well do it right.

For the long version, read crackstation.net

For the short (PHP) version, read on!

1. Never, NEVER EVER, store the users password. No if's or but's.
2. $hash = md5($password) is not very good. Do it better.
3. Just because your system is small, not widely used, blah blah blah, whatever your excuse, you should still do it right. You just never know where your code will end up!

Do it right

• Go to crackstation.net/hashing-security.htm#phpsourcecode
• Click on "Download PasswordHash.php"
• Use these (public domain) functions in your code

What it looks like. Code sample:

function validate_password($password, $good_hash)
{
    $params = explode(":", $good_hash);
    if(count($params) < HASH_SECTIONS)
       return false;
    $pbkdf2 = base64_decode($params[HASH_PBKDF2_INDEX]);
    return slow_equals(
        $pbkdf2,
        pbkdf2(
            $params[HASH_ALGORITHM_INDEX],
            $password,
            $params[HASH_SALT_INDEX],
            (int)$params[HASH_ITERATION_INDEX],
            strlen($pbkdf2),
            true
        )
    );
}

More PHP grief

I'm sorry, but I just have to link to this article:

I'm sorry, but PHP sucks

For example, from Point 3:

(string)"false" == (int)0> is true

Look, if you use PHP regularly, it's worth reading the good and the bad to better understand your tool. And in any case, he does finish with this:

That said, I am a huge advocate for choosing "the right tool for the job" and that, or course, means that you might want to choose PHP under the right circumstances. I'll give you a few examples:
- You have found the ideal framework or base for your software and it's written in PHP
- You already have a huge investment in PHP technology
- Your time-constraints do not allow you to learn something else

Logging revisited

If you're logging to a file - but of course you're logging to a database aren't you!? - but, if you are logging to a file, it's PHP so of course, there's a function for that:

file_put_contents($file, $data, FILE_APPEND|LOCK_EX)

From the manpage:

This function is identical to calling fopen(3), fwrite(3) and fclose(3) successively to write data to a file.

And of course, add the LOCK_EX only if you care about not corrupting your logfiles!

Enjoy! :)