For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Julian_Grunnell's avatar
Julian_Grunnell
Icon for Nimbostratus rankNimbostratus
Jun 13, 2007

Cookie Rewrite & ASPSESSIONID Mk. II

Hi - well looks like my previous post got foobar'd somehow. Anyway thanks to willms & hoolio for their valuable input!!

 

 

I amended willms iRule slightly to:

 

 

when HTTP_RESPONSE {

 

set ASPID [findstr [HTTP::cookie names] "ASPSESSIONID" 0 20]

 

set debug "1"

 

if { $ASPID ne "" } {

 

if $debug {log local0. "ASPSESSIONID FOUND $ASPID"}

 

}

 

else {

 

if $debug {log local0. "ASPSESSIONID NOT FOUND"}

 

}

 

}

 

 

And the ltm log showed:

 

 

Jun 13 09:37:02 tmm tmm[952]: Rule ASPTEST : ASPSESSIONID NOT FOUND

 

Jun 13 09:37:02 tmm tmm[952]: Rule ASPTEST : ASPSESSIONID NOT FOUND

 

Jun 13 09:37:03 tmm tmm[952]: Rule ASPTEST : ASPSESSIONID FOUND ASPSESSIONIDCCDATSAB

 

Jun 13 09:37:03 tmm tmm[952]: Rule ASPTEST : ASPSESSIONID FOUND ASPSESSIONIDCCDQCBQR

 

Jun 13 09:37:03 tmm tmm[952]: Rule ASPTEST : ASPSESSIONID FOUND ASPSESSIONIDQQSCDCQQ

 

Jun 13 09:37:03 tmm tmm[952]: Rule ASPTEST : ASPSESSIONID NOT FOUND

 

 

So we can capture the ASPSESSIONID info.

 

 

When we originally tried cookie insert the customer complained of some of his customers being logged out or told they were not logged in. A sympton of being re-load balanced and presenting an ASPSESSIONID that the server knew nothing about? Unfortunately we didn't capture any tcpdump or header info at this stage so are going of memory!! But I agree with you hoolio the load balancing should work irrespective of what cookie the node might set.

 

 

The whole problem with failure is that I've not seen any, the site is VERY busy and tcpdumps are 100mb+ in less than a minute. And we rely on the customer getting complaints from his clients accessing the site. It's all very messy to work out I'm afraid.

 

 

Thanks again - Julian.
application delivery
dev
devops
iRules

8 Replies

  • JRahm's avatar
    JRahm
    Icon for Admin rankAdmin
    Jun 13, 2007
    I also saw occassional issues with cookie persistence, so I use the session table to build the backend pool member reference from the sessionID. Maybe not the most efficient way, but I don't have any issues with it.

    
   when HTTP_RESPONSE {
    if { [HTTP::cookie exists "ASPSESSIONID"] } {
      if { [session lookup uie [findstr [HTTP::cookie names] "ASPSESSIONID" 12 20]] equals "" } {
        session add uie $sessionID [IP::server_addr] 1800
        log local0. "added server entry [session lookup uie [findstr [HTTP::cookie names] "ASPSESSIONID" 12 20]]\
          for aspsessionID [findstr [HTTP::cookie names] "ASPSESSIONID" 12 20] "
      } else {
        log local0. "existing server entry [session lookup uie [findstr [HTTP::cookie names] "ASPSESSIONID" 12 20]]\
         for aspsessionID [findstr [HTTP::cookie names] "ASPSESSIONID" 12 20]"
      }
    }
  }
  when HTTP_REQUEST {
    if { [HTTP::cookie exists "ASPSESSIONID"] } {
      if { !([session lookup uie [findstr [HTTP::cookie names] "ASPSESSIONID" 12 20]] equals "") } {
        pool [LB::server pool] member [session lookup uie [findstr [HTTP::cookie names] "ASPSESSIONID" 12 20]]
        log local0. "aspsessionID [findstr [HTTP::cookie names] "ASPSESSIONID" 12 20] 
          \sent to [session lookup uie [findstr [HTTP::cookie names] "ASPSESSIONID" 12 20]]"
      } else {
        pool [LB::server pool]
        log local0. "No aspsession ID, load balancing the connection..."
      }
    }
  }
  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Jul 18, 2007
    I noticed that SOL5714 (Click here) describes some possible reasons for cookie persist failures. I wonder if any of these issues may have affected your testing with cookie insert persistence...

     

     

    Aaron
  • Deb_Allen_18's avatar
    Deb_Allen_18
    Historic F5 Account
    Jul 18, 2007
    what am I missing here?
    if { [session lookup uie [findstr [HTTP::cookie names] "ASPSESSIONID" 12 20]] equals "" } {
    Wouldn't this look for a session table entry keyed on the 20 char following the string "ASPSESSIONID" in the list of cookie names... which would be the name of another cookie (or cookies), if any were listed after ASPSESSIONID, rather than the expected ASPSESSIONID cookie value itself...?

     

     

    If so, that could certainly work well most of the time, but result in persistence failure if the list of cookies returned by the server ever changed.

     

     

    To just extract the cookie values directly, adjusting your code accordingly, something more along the lines of:
    
when HTTP_RESPONSE {
  set sessionID ""
  if { [HTTP::cookie exists "ASPSESSIONID"] } {
    set sessionID [HTTP::cookie ASPSESSIONID]
    set persistTo [session lookup uie $sessionID]
    if { $persistTo equals "" } {
      session add uie $sessionID [IP::server_addr] 1800
      log local0. "added server entry $persistTo for aspsessionID $sessionID"
    } else {
      log local0. "existing server entry $persistTo for aspsessionID $sessionID"
    }
  }
}
when HTTP_REQUEST {
  set sessionID ""
  if { [HTTP::cookie exists "ASPSESSIONID"] } {
    set sessionID [HTTP::cookie ASPSESSIONID]
    set persistTo [session lookup uie $sessionID]
    if { $persistTo equals "" } {
      pool [LB::server pool]
      log local0. "No aspsession ID, load balancing the connection..."
    } else {
      pool [LB::server pool] member $persistTo
      log local0. "aspsessionID $sessionID sent to $persistTo"
    }
  }
}

     

     

    I also dug up a a somewhat simpler version using "persist" instead of "session" I helped implement a while back & added it to the codeshare ()

     

    HTH

     

    /deb

     

  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Jul 19, 2007
    Some background info on the aspsessionid cookie:

     

     

    IIS sets a cookie named ASPSESSIONID followed by 20 alpha characters. The 20 characters are dynamically generated based on the process ID of the IIS instance. So as long as the instance is up, the dynamic string will be the same. If the instance is restarted, the PID changes and consequently the dynamic string changes.

     

     

    So you can persist off of the cookie name as a whole, or just the dynamic part of the string. There are a few advantages to using this method instead of the cookie value:

     

     

    - the cookie name changes less frequently compared with the cookie value

     

    - you don't have to worry about the client changing the cookie value

     

    - you only have one persistence record per web server--instead of one per client.

     

     

    Aaron
  • Deb_Allen_18's avatar
    Deb_Allen_18
    Historic F5 Account
    Jul 20, 2007
    How Bizarre. Thanks for cluing me in.

     

     

    I've updated the codeshare example to include that example as well.

     

     

    /deb
  • Deb_Allen_18's avatar
    Deb_Allen_18
    Historic F5 Account
    Jul 20, 2007
    So does this command really return True for a cookie named ASPSESSIONIDabcdefghikjklmnopqrs?
    HTTP::cookie exists ASPSESSIONID

    /deb
  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Jul 20, 2007
    Nope. You could look for it by looping through the cookie names looking for starts_with aspsessionid.

     

     

    Aaron
  • Deb_Allen_18's avatar
    Deb_Allen_18
    Historic F5 Account
    Jul 20, 2007
    OK, good to know.

     

     

    Both approaches are documented in the codeshare page:

     

    http://devcentral.f5.com/wiki/default.aspx/iRules/ASP_SessionID_Persistence.html (Click here)

     

     

    I left out the test for the existence of the cookie in the PID-based example, since lack of matching session table entry will cover it.