As bad fortune had it, though, I found out that Verizon's byzantine labyrinthine billing system had just discovered that while I do have fiberoptic internet coming to the house, I do not have any phone numbers associated with it, as I moved the phone and fax line over to Vonage.
So Verizon did the smart thing. Since your "customer number" is the same as your phone number and I don't have a phone number with 'em, they deleted the account. So it took an hour of Shelly wrangling with Verizon and eight hours of "your internet should be back up within two hours", we had internet and phone back up.
Kudos to Vonage for their new service that rolls over calls to another phone number if your Vonage box is unreachable. We had it set to roll over calls to Shelly's cell-phone, and we didn't miss any calls.
While the internet was down, I took advantage of the time to make a couple of changes to the protection scheme. It's notoriously easy to "steal" Flash applets from someone's server, but there are a few things you can do to at least prevent casual theft. One thing that's common is to put a text file on your server that looks like this:
magicPassword=abracadabra
While your applet loads, it grabs that text file off your server, checks the value, and runs only if it's what you expect (i.e. "abracadabra"). Since a Flash applet (like a Java applet) can only talk to the server that created it, putting the applet on another server will make the applet refuse to run.
Just because I could, I went a step further. Rather than a text file, I check a PHP "magicPassword" file. When I want to grab the file from the server, I pass it a random string of digits. The file then returns that string, after encrypting it a bit. My applet then decrypts that string, compares it to the original, and runs if they match.
That's step four of the protection. . .
Step one is that the HTML "unframes" itself if it sees that some other site has it in a frame.
Step two is that the applet itself re-launches its surrounding page if it sees that its surrounding HTML isn't coming from thecodezone.com (i.e. someone tries to embed the applet on their page without copying it from my server).
Step three is that the applet is encrypted. Many Flash people poo-pooh Flash obfuscators, but I haven't found a commercial decompiler yet that can get reasonable code from it.
Far as I can tell, these four steps are about the limit of Flash applet protection right now. The only reasonable way to run my game on another site right now is to decompile the applet and remove the protection from the obfuscated code. And, frankly, if you're willing to work that hard for some little puzzle games, you're better off just writing 'em from scratch :)
The upshot is that I'm about a day away from unveiling the ChessCards Daily Puzzle. I do look forward to you seeing it.
The way the game works is that you're presented with a daily puzzle. Everybody gets the same puzzle. You have to slide cards around until you solve the puzzle. Once you solve the puzzle, you enter your name. The next day you can check back to see how well you did. . .and play the next day's puzzle.
ChessCards isn't an ideal puzzle for the daily puzzle format, because I find that each puzzle takes 10-15 minutes to solve. I plan to introduce a couple more similar games in the coming two weeks that are much faster (1-2 minutes).
It's almost there. I promise!
