Jason McMunn

Tech Ranting and Raving

RSS Feed

Tealeaf + F5 super easy TLTSID

0 Comments

So I’ve become completely immersed in Tealeaf Awesomeness over the last year. It started out with doing some fraud research in a partnership with the Web Analytics team that turned into us basing the core analysis of our overall application fitness on Tealeaf. Then I decided to blend in the F5 (another favorite technology). The problem we were solving is that our backend website is serviced by almost a dozen groups of servers. Weblogic Domains, Apache Server (for media assets only), Search servers, etc. We did not have a single tier other than the F5 with which to inject Tealeaf’s TLTSID and TLTUID cookies. This is obviously a place for the F5 to shine.

To start with, we had to generate a value.  This value had to mimic the value that comes from Tealeaf natively so that it would blend in with their cookie when we crossed datacenters into facilities that did not use F5s (and used the traditional cookie injector).  The value is essentially a 32bit value written out in uppercase Hexidecimal.

I also need a low impact method of generating a relatively unique ID.  I don’t need it to be a true GUID, but I don’t want two users getting the same value (or honestly, even a similar value because we write it out to log files and you want to be able to visibly unique them based on a few characters.

So I came up with this for the algorithm to generate the unique value:

md5 "[IP::client_addr][TCP::client_port][clock seconds][expr rand()]"

This gave me a hash of something that should be fairly unique. If you’re using a DMZ tier you may have all traffic appear from a single SNAT address, but that’s a story for a different post.  I add to that the client port.  If you’re doing pipelining from something like Akamai, you may get multiple connections from a single IP and port combo.  Adding on clock seconds and a random number should make them truly unique.  The hash is probably overkill.

The MD5 hash function in TCL returns a binary value, so I perform a Hex transformation on it by passing it through the binary function with a scan option and the field specifier of H* hex.  This is not an obvious function and I spent a fair amount of time digging through this in the TCL man pages.  Finally I upcase it with this:

set tltsid [string toupper $hex]

The other thing this does for me is set the value to be retained.  I’m only executing this block if the cookie isn’t set, and I’m setting it in a variable so that I know if I should set it on the response.  There is no reason to set the cookie if it’s already set.  I don’t know if it’s already set between the HTTP_REQUEST and the HTTP_RESPONSE unless I explicitly set a variable.

 

Now I set up some logic in the request to test for the cookie being set.  I use that to wrap the creation of the string and to decide when to display it.  I check that with:

[HTTP::cookie exists "TLTSID" ]

Later in the response(HTTP_RESPONSE) section of the irule, I test for the value with:

if { not ( $tltsid equals "") }

 
Here is the final irule:
 

when HTTP_REQUEST {
   if { ([HTTP::cookie exists "TLTSID" ]) } {
      set tltsid ""
   }
   else {
      binary scan [md5 "[IP::client_addr][TCP::client_port][clock seconds][expr rand()]"] H* hex
      set tltsid [string toupper $hex]
      HTTP::cookie insert name "TLTSID" value $tltsid path "/" domain ".tld.com"
   }
   if { ([HTTP::cookie exists "TLTUID" ]) } {
     set tltuid ""
   }
   else {
      binary scan [md5 "[IP::client_addr][TCP::client_port][clock seconds][expr rand()]"] H* hex
      set tltuid [string toupper $hex]
      HTTP::cookie insert name "TLTUID" value $tltuid path "/" domain ".tld.com"
   }
}

when HTTP_RESPONSE {
   if { not ( $tltsid equals "") } {
      HTTP::cookie insert name "TLTSID" value $tltsid path "/" domain ".tld.com"
   }
   if { not ( $tltuid equals "") } {
      HTTP::cookie insert name "TLTUID" value $tltuid path "/" domain ".tld.com"
      HTTP::cookie expires "TLTUID" 51840000 relative
   }
}
Filed under Uncategorized

Rackspace sadness

0 Comments

So I am a big fan of rackspace cloud.  I’ve been using them since they were Mosso.  I’ve recently started collaborating on a new endeavor with a guy who’s got a great idea.  I’m looking to bring in the the tech backend.

So I was going to throw up a “coming soon” page and decided this time I’d do things a bit differently.  In the past when I collaborated with someone on a site I’d usually just add it to my “account” and it’d show up as one of my sites for editing.  Makes splitting it off later a hassle and it doesn’t seem like the “right way to do it”.  So I set the new site up with a distinct sub account.

I go into the “ftp user” section of the security tab and go to add myself to his site as an editor… “This username is already taken”.  Wait.. what? I have to create a new account just for editing his site? This can’t be right.  Sure enough it is.  I talked to tech support and you can’t attach existing accounts to subaccounts as editors.

The confirmed that if I wanted to collaborate with 10 people on 10 sites, I would have to create 10 additional usernames for myself with 10 different passwords(or i guess they could all be the same).

What a failure.

Thumbs down rackspace.  Thumbs down.

Filed under Rants

Categories

Meta

Blogroll