Well, no, not any query.  I would never want to kill a write — just a read-only query; in particular: search queries.

So, as it turns out, the hurdles for this are immense, and, because my solution uses PHP’s pcntl_fork() function, even my solution, while it works, it has to make assumptions and is not perfect.

That being said, it would seem easy enough for this to be built into PHP or for some similar mechanism to be built into MySQL: Execute this query but only if it takes less than n seconds.  If not, kill it.  This is not the case, however, so we’re left to our own cleverness.

There are hundreds of reasons why you would never want to do this, but I only need one reason to want to do it to try to implement it.

So here is my solution steps in techno-layman’s terms, followed by the necessary code:

• Call a function to execute a MySQL query (again, preferably read-only)
• Open a shared memory space so that we can pass the query results back to the parent from the child
• Store process state information in a database
• Fork, and execute the query in the child process
• Keep time in the parent process
• Kill the child process if it takes longer than n seconds
• Return the results

Just to forwarn, I have tested this as proof of concept, but I am uncertain about the particulars of PHP’s shared memory and am not confident how reliable the shared memory implementation will in a production environment.  I plan to try it out, but right now I’m just getting the info out there.

So the state database will be defined as follows:

CREATE TABLE IF NOT EXISTS `pcntlFork` (
`idx` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`status` enum('0','1') NOT NULL DEFAULT '0',
`output` longblob NOT NULL,
PRIMARY KEY (`idx`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=58 ;

The PHP class is available to download here:  http://mysql-restrictor.googlecode.com/files/mysqlRestrictor.class.php (I had it inline, but WordPress did not want to format it properly)

And you would use it something like this

$m = new mysqlRestrictor();
$results = $m->dbQuery("SELECT * FROM `table`");
var_dump($results);

Since this took me an extremely long time to build and just verify that it even works, I welcome comments for improvement, and by all means use it for yourself. Let me know how it does in production!

Maybe I’m just keeping this for my own future reference, but maybe someone else out there could use it too. 

The function generates a string containing numbers and letters only (it’s easily customizable to contain other chars).  The form just creates inputs with random names from the string generator and random values from the string generator.


function randomString() {
        $chars = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ';
        for ($i=0; $i<rand(10,20); $i++) { $string .= $chars[rand(0,strlen($chars))]; }
        return $string;
}

?><form action="" method="POST"><?php
        for ($i=1; $i<=rand(5,10); $i++) { ?><p /><input name="<?php echo randomString(); ?>" value="<?php echo randomString(); ?>" /><?php }
        ?><p /><input type="submit" /><?php
?></form><?php


It’s easy to find the documentation to do PayPal Express Checkout, but to find that one little field where you send an alternate user as the recipient of the payments, well that’s downright impossible.  It is not in the docs (at least not as of this writing 5-18-2011).

How simple is it? Very — the variable is “SUBJECT”

Yes, you specify an alternate “SUBJECT” of the transaction.

Normally your SetExpressCheckout request looks something like:

METHOD=<method_name>&VERSION=<version>&PWD=<API_Password>&USER=<API_UserName>&SIGNATURE=<API_Signature>&...

Now it will look like this:

METHOD=<method_name>&VERSION=<version>&PWD=<API_Password>&USER=<API_UserName>&SIGNATURE=<API_Signature>&SUBJECT=<Payee_PayPal_Account>...

Payee_PayPal_Account is the email address/username the user uses to log in.

Hope this helps!  Took us valuable time to find …

That being said, one of the major issues I’ve had is that the Xorg select/paste always copies tab characters as the corresponding number of spaces.  So, when I select text in one file, paste into another, I have to replace all the spaces with tabs.

Typically I paste into gedit first, do the replace there, then c/p into the file.  This preserves the tabs.

(If you’re still wondering why I use nano, I just like having my editor accessible as long as I have server access.  I never got used to vi, and nano is more than effective for me.)

I have always thought nano should be able to search and replace tabs and spaces, but I could never get it to work.  Even without the gedit technique, I would typically just replace all double spaces to nothing, then manually insert the tabs.  My workarounds, again, are generally sufficient.  I have not NEEDED search and replace of tabs within nano, but today I decided I wanted to really find out if I could.

And it required some digging …

But, I finally found it: verbatim input!

Nano has a feature to disable character interpretation, and for one character, accept input literally.

To turn it on (again it’s for just the first character typed), hit alt-SHIFT-V (alt-V without shift may trigger x-windows menus), then just hit the tab key (it may or may not show a note that you’re in verbatim input mode).

You only need to do this in the search / replace prompts.  Obviously, you can type tabs directly into the file.

So an example — let’s say you want to convert any instance of 8 spaces to a tab character.

Here is the command stack:

control-W (search)
control-R (replace)
hit space 8 times, then hit enter
alt-shift-V (verbatim input)
hit the tab key, hit enter

Proceed as normal.

Hopefully this post is easier to find than the seemingly impossible digging I just undertook …

It took my quite a long time to figure out how to get it to change to that directory then stay logged in, even though it is rather simple.  It also took my a long time again recently because I reinstalled without backing that up.  So, this post is mainly so I don’t have to do that again, but maybe it will help others too.

The trick is to make SSH behave like a terminal (with the oft-overlooked -t flag), then to execute a login bash shell using normal SSH command execution.

So:

ssh -t ‘cd /path/to/go/to; bash -l’

So for me, my shortcut in the gnome taskbar is

gnome-terminal –tab -e “ssh -t ‘cd /path; bash -l’” –tab -e “ssh -t ‘cd /path; bash -l’” –tab -e “ssh -t ‘cd /path; bash -l’”

There — saved myself (and you) some time!

It, shamefully, just clicked with me the power of rainbow tables (for which I only learned the term in the last few days).  For some background, any legitimate website or authentication system does not store your password in plain text.  It uses a one-way encryption and stores that encryption.  Then to check if you used the right password, it encrypts the one you send it and compares it against the stored encryption.  This minimizes opportunities for a copy of your password to be easily accessible, decryptable, or readable, in any sense to someone who want to use it for malfeasance.

The trick with all one-way encryptions used for such “hashing” purposes is their resulting strings are fixed length.  For example, sha1, which is probably the most widely used method on the web, creates alphanumeric (0-9, a-z not case sensitive) hexadecimal strings of length 40 (at least using the php sha1() method with which I am familiar — I’m not a sha1 expert).  Because of this, there are possible collisions.  In other words, although your password might encrypt to one string, there are effectively infinite other strings that would encrypt to that same string.

Before getting too uptight about this, just do the basic numbers.  The sha1 encryption creates 40 character strings with 36 16 possible characters in each place, meaning there are 36^40 16^40 possible resulting encryptions.  That number?

178,689,910,246,017,054,531,432,477,289,437,798,228,285,773,001,601,743,140,683,776
1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976

Is there even a word for that?  Yes … 178.69 novemdecillion 1.46 quindecillion.  (that is a big number)

So a hacker would build the corresponding rainbow table by finding exactly 1 string that converts to each of those 178,689 1,461,501 … hashes.  Then, somehow, they get your encrypted password, and all they have to do is look it up in this table, and they have your password (or at least one that collides with yours’ hash).

It is very simple, but, fortunately, at this point, that rainbow table would not fit on all the hard drives in the world.  In fact, it would take about 50 billion earths to find an equivalent number of atoms the earth is only composed of about 133 quindecillion atoms. (That’s one hash per 89 atoms — a human hair is about 10000 atoms thick).

But let’s abandon the seeming impossibility of the existence of this table temporarily.  A common practice in secure storage of passwords these days is to “salt” the password before hashing and storing it.  That is, you take the password, prepend (or append) a random string, then encrypt the resulting string.  (More complex salts can exist, but the idea is that you modify the password in a predictable, repeatable way).  What this does is force a hacker to build a corresponding rainbow table for EVERY password he/she wants to hack, because the unsalted rainbow table won’t work (I’ll leave this to you to figure out why if you don’t know at this point.)

The problem is, if you’re still using sha1 to encrypt the salted password, it’s no different than if you didn’t salt the password.  If this complete sha1 rainbow table DID exist, the salt would serve absolutely no purpose, it would just shift the collision.  Some infinite subset of strings would still map to this encrypted string.

As a side note, the rainbow tables that exist are simply compilations of common types of passwords, and, in many instances, they work, because people just don’t use strong enough passwords.  This reduces the size of the tables to a usable form, so, in this case, the salting is imperative.  I am discussing today the case where a complete sha1 rainbow table exists.  I have said that it is pretty much impossible, but, from a purely theoretical standpoint, eventually, even the number 178.69 novemdecillion 1.46 quindecillion will become small as technology improves with time.

By the way, “strong,” for all intents and purposes of one-way hashing, just means long.  Knowing a password is short drastically decreases the number of hashes that need to be generated for the table.  Good advice? Use passwords 20 characters or longer — i.e. a sentence “This is my password, baby. Nothing personal, but don’t steal it.”

My question is, is it really effective to use the same encryption mechanism after you salt the password?  Salting is little more than an obfuscation in the presence of a complete rainbow table.  In the face of the assumed existence of this rainbow table, and ignoring that most passwords aren’t truly “random,” there is exactly no difference between “salt and hash” and simply “hash.” This just leads me to the conclusion that the inherent flaw in one way hashes is that they create strings of finite length, but that is exactly why they are useful.

Perhaps the only purpose of this post was to legitimately use the word novemdecillion quindecillion more than once.  I dunno, but I would certainly appreciate expert commentary on the topic.

Edit: After initially writing this, I realized that sha1 created hex strings, not alphanumeric.  This changed the numbers, but fortunately not the article.  I decided to leave the old numbers in strikethrough because, well, novemdecillion is a cool freaking word.

Then you’ll get to programming and realize that the documentation is pretty crappy, but specifically I want to address the idiosyncrasies of the USPS “test” environment.  Effectively, what USPS means when they say “test” is not a test of robustness of your application, but simply whether or not your application can build a sample request (an EXACT sample request), and send it to their server.  Yeah — it’s like asking a math teacher to write the numbers 1 to 30 on a sheet of paper (in order) before he/she can get hired.

The problem is, the USPS docs don’t tell you this, nor do they show you the sample request.  So, for others who are about to embark on a few hour journey finding these details on Google (or worse, emailing USPS directly …eeek) I’m going to sum up a few facts here.

The most laborious for me so far is the one I already mentioned above.  For a rate request, the docs show you a RateV3Request, but in testing you can only use a RateV2 request (which does not support package dimensions).  Also, you must use the zip codes 10022 and 20008 for origination and zip, as well as 10 lbs. 5 oz. for the weight, and “LARGE” for the size.  Everything else (LAUGH) you have leeway with.

If you don’t use these exact values, you’ll get responses like “Please enter a valid zip code for the sender” (which of course makes you think you wrote the XML incorrectly) or “The package size must be ‘Regular’, ‘Large’, or ‘Oversize.’” (even though you have “regular” quite clearly in the request.

The advice is to get to production as soon as possible, though why USPS would design things this way is beyond me, but them’s the cards, you gotta play ‘em.

I will add more here as I find them obstaclicious enough (yeah I just made up that word).

Amendment 1:  I should add that the issues about the documentation not mentioning the “canned” requests is only applicable to the PDF documentation.  It is stated quite clearly in the HTML versions.  Go figure …

The process of hiding them actually took me a little bit to figure out, so I thought I’d share.  It’s rather simple, so don’t blink! 

Simply edit “index.php” in the wp-content/themes/<your_theme_here>/ directory.

Between the lines:

<?php if (have_posts()) : ?>

and

<?php while (have_posts()) : the post(); ?>

Insert the line:

<?php if (is_home()) { query_posts("cat=-XXX"); } ?>

Be sure to replace “XXX” with the unique numeric ID of the category you want to ignore.  To find the ID, log into your admin, navigate to your categories, and select the one you want to ignore.  The number will then appear in the URL.

NOTE: Make sure you don’t delete the “-” before the “XXX” or else you will ONLY show entries from the category.

If you update your theme, you will probably have to repeat this procedure.

If you want to hide multiple categories simply append the other categories to the string with a comma: (Example: “cat=-12,-82,-4″)

It also follows, then, that this technique can also be used to hide tags, posts, etc.

Based on the same engine as http://abv8.me/ and http://ihrt.it/ (developed by my web company, geeXmedia).

I plan soon to launch URL shorteners on http://tharp.me/ and http://tharp.us/

My business partner Chris and I have made our 3rd voyage to eBay DevCon, this year in wonderful San Jose in northern California (where the girls are warm so I could hear my sweet baby say … ).

We flew in last night, Jet Blue flight 317 direct from Washington Dulles to Oakland International.  Oddly enough, Chris’ neighbor Tooland happened to be the pilot, and he hooked us up with a free Heineken — yeah baby.  Anyway, it was a very long 6 hour flight (it was only 6 hours 23 minutes in the air when I flew to Paris from Philly), and we had some rocky air with a little detour as there were t-storms and tornadoes in Kansas.

We touched down at around 9pm local time (12am EST) and headed over to Budget Rental where we picked up our awesome Kia compact POS.    Actually, it’s not too bad — good turning radius and small — hard for all the crazy California drivers to smash into.  We got to the hotel at 10:30 or so and proceeded to pass out.

So here we are in beautiful San Jose.  Well, cities are just cities, and, being the tree fanatic that I am, we had to visit the redwoods.  We got up early this morning — 6:30 or so, and decided to make our way to the Big Basin Redwoods State Park.  Now, for whatever reason, we put “shortest distance” into the GPS instead of “fastest time,” and we ended up on California route 35 — heading across the mountains on one of the steepest, windiest, but most scenic roads, I could have ever imagined.  I got some awesome pics of northern California vegetation, and, finally, about 2 hours later, we got to the park.

Now let me tell you, the coastal redwoods surprised me.  For all that they are huge, in the grand scheme of things, they really don’t seem all that large.  Really, a 300ft tall tree is only as tall as a football is long.  Gargantuan for a tree, yes, but in the grand scheme of things, they just feel like another tree — just ones that dwarf any big tree we have back east.  That being said, they are so tall and straight, they are kind of modest.  If a broad, bushy oak grew 300ft tall with a 200ft wide crown, I doubt I could relate to the perspective of such a tree being so modest.

From the park, we made our way to Santa Cruz so we could at least see the Pacific ocean.  We spent a little time at Seabright beach http://abv8.me/2R, and ate at a nice little place on the wharf named Aldo’s.  Apparently Guy Fieri ate there once.  The burger was delicious, and we had a little European Starling join us for a bite.  We named him Fred, and we were the best of buds.

From there, we headed back up route 17 to the eBay campus here in San Jose to listen to Madhu Gupta and company present the basic ins and outs of the new eBay selling manager pro applications platform.

General high points:

• eBay items trade at a velocity of $2000/second
• Some eBay sellers might put more trust in third party apps if they appeared to be hosted by eBay
• eBay decided to make a platform where third party developers could integrate with eBay in a smart iframe or in hosted HTML
• They will use the open gadgets specification
• This will launch in August

Now, we have already developed our first application for this platform.  It is eZ labelZ for eBay, and it is a variation on our site ezbarcodez.com — geared to provide great integration with the already present eBay APIs so that sellers can print functional labels for their items.

Since we have been involved in the project since the alpha, most information was nothing new, but it was good to get a concrete overview.

Afterwards was “Happy Hour” with free beer and hors-d’oeuvres, and some networking.  We had some great chats with some eBay personnel, especially the documentation team, and well, what can I say?  Free beer.

So now we’re back at the hotel and I have hundreds of pics to parse through.  Hopefully they will appear on Facebook tonight and I will link them here.