What could you do with your code in 20 Lines or Less? That's the question I like to ask for the DevCentral community, and every time I go looking to find cool new examples that show just how flexible and powerful iRules can be without getting in over your head.

This week’s examples deal with things ranging from session persistence (And NOT for JSESSION!) to RADIUS authentication and beyond. Ask and the community shall provide, as is so often the case, adn this week was no different. Let’s see what we came up with in this week’s 20LoL:

 

ASPSESSIONID Persistence

https://devcentral.f5.com/questions/irule-required-to-persist-client-connections-that-get-proxied-from-a-single-client

We’ve seen the JSESSIONID version enough times that it should be committed nearly to memory by now, I would think. This take, however, is a bit newer. It is of course the exact same concept, but rather than dealing with Java, user Nathan Andrews was looking for a way to persist data from Blackberries accessing an application. Source address wasn’t working since they were bouncing through a proxy inherent in such deployments. Fortunately he was able to identify a common attribute and persist based off of that. Enter ASPSESSIONID and handy, likely familiar chunk of code.

when HTTP_RESPONSE {
  if { [HTTP::cookie exists "ASPSESSIONID"] } {
    persist add uie [HTTP::cookie "ASPSESSIONID"]
  }
}
when HTTP_REQUEST {
  if { [HTTP::cookie exists "ASPSESSIONID"] } {
    persist uie [HTTP::cookie "ASPSESSIONID"]
  }
}

Radius and WebApp Authentication

https://devcentral.f5.com/questions/radius-and-webapp-authentication

DC user Don Benson was looking to collect three bits of data to perform Radius Auth for a web app, using their BIG-IP to collect and pass through the required data. They were looking for username, password and a hardware token. The trouble in their testing came when the web app was expecting a POST and they were sending GETs (not sure quite what they were doing since they didn’t post their original iRule). Fortunately another helpful DC member chimed in with a suggestion that, if my math is correct…carry the one…should get them where they need to go.

when ACCESS_POLICY_COMPLETED {
  set username [ACCESS::session data get "session.logon.last.username"]
  set content "< script type=text/javascript language=javascript> \
    function s(){ document.f.submit(); }  \
     \
    
    "
  ACCESS::respond 200 content $content
}

URI Queries and Fancy Footwork

https://devcentral.f5.com/questions/how-to-destroy-and-replace-a-uri-query-value-

While the original thread’s title was about destroying and replacing URIs, I thought this more appropriate. Nitass steps in with some handy dandy URI query shaping logic to make what sounded like a somewhat complex set of deliverables a snap. Looking to replace a query parameter with a specific value, or ensure said query param is in place if its missing? Well here you go.

when HTTP_REQUEST {
  if { [HTTP::host] eq "red.x.com" } {
    set q [URI::query [HTTP::uri] code]

    if { $q ne "" } {
      HTTP::uri [string map "$q red" [HTTP::uri]]
    } else {
      HTTP::uri "[HTTP::uri]&code=red"
    }
  }
}