Forum Discussion

OTS02's avatar
OTS02
Icon for Cirrus rankCirrus
Nov 29, 2011

universal persistence using jsessionid

Have Universal persistence set up and use this irule:

 

 

when HTTP_RESPONSE {

 

if { [HTTP::cookie exists "JSESSIONID"] } {

 

persist add uie [HTTP::cookie "JSESSIONID"]

 

log local0. "[IP::client_addr] Clairmail persistence HTTP_Response [HTTP::cookie "JSESSIONID"]"

 

}

 

}

 

when HTTP_REQUEST {

 

if { [HTTP::cookie exists "JSESSIONID"] } {

 

persist uie [HTTP::cookie "JSESSIONID"]

 

log local0. "[IP::client_addr] Clairmail HttpRequest [HTTP::cookie "JSESSIONID"]"

 

}

 

}

 

 

Works great with IE, but some boutique browsers append extra cookies. If the original jsession cookie does not happen to be first in the list, the LTM treats it as though it is not there, and persistence fails. I know there must be a way to force the LTM to look into the whole string.

 

 

Grateful for any help.
  • You could try creating a unique ID for the cookie, persist on it and then insert the cookie in responses. But you're basically just manually recreating what the default cookie insert persistence profile does. So why not just use that?

     

     

    I think you could probably use that instead of the JSESSIONID persistence iRule. The JSESSIONID persistence iRule is only really useful if you need to persist at multiple tiers (client to web and web to app) or if clients don't support cookies and need to use the JSESSIONID in the URIs.

     

     

    Aaron
  • This is for mobile banking. The enrollment phase requires that I grab a jsessionid from an inhouse server, and use it for persistence for the incoming client session (the one wanting to enroll). I know that is cumbersome, but that is the way the product works.
  • Tried this, and it may be working.

     

     

    when HTTP_RESPONSE {

     

    if { [HTTP::cookie "JSESSIONID"] ne ""} {

     

    persist add uie [HTTP::cookie "JSESSIONID"]

     

    log local0. "[IP::client_addr] Clairmail persistence HTTP_Response. Cookies: [HTTP::header values Cookie]"

     

    }

     

    else {

     

    set rndumb [expr { int(100000000 * rand()) }]

     

    HTTP::cookie insert name "JSESSIONID" value [HTTP::cookie value $rndumb]

     

    log local0. "[IP::client_addr] assigned a random cookie, $rndumb"

     

    }

     

    }

     

    when HTTP_REQUEST {

     

    if { [HTTP::cookie "JSESSIONID"] ne ""} {

     

    persist uie [HTTP::cookie "JSESSIONID"]

     

    log local0. "[IP::client_addr] Clairmail HttpRequest. Set-Cookies: [HTTP::header values Cookie]"

     

    }

     

    }

     

     

    Can you tell me how to convert the random decimal to hex? Or maybe how to generate a random hex stream?
  • Well, I can't say I understand the full scenario, but... here goes anyhow.

    You may want to remove the spoofed JSESSIONID cookie from requests before they're sent to the pool. You could try something like this:

    
    when HTTP_REQUEST {
    if { [HTTP::cookie "JSESSIONID"] ne ""} {
     Perist on the JSESSIONID or spoofed value
    persist uie [HTTP::cookie "JSESSIONID"]
    log local0. "[IP::client_addr] Clairmail HttpRequest. Cookies: [HTTP::header values Cookie]"
    
     Remove spoofed cookie
    if {[HTTP::cookie "JSESSIONID"] starts_with "ltm_"}{
    HTTP::cookie remove "JSESSIONID"
    }
    }
    }
    when HTTP_RESPONSE {
    
     Check if the app did not set a cookie
    if { [HTTP::cookie "JSESSIONID"] eq ""} {
    
     Insert a spoofed cookie in the response for persistence
    set rndumb "ltm_[expr { int(100000000 * rand()) }]"
    
    HTTP::cookie insert name "JSESSIONID" value $rndumb"
    log local0. "[IP::client_addr] assigned a random  cookie, $rndumb"
    
     Add a persistence record using the random number
    persist add uie $rndumb 3600
    
    } else {
    
     Add a persistence record using the JSESSIONID 
    persist add uie [HTTP::cookie "JSESSIONID"]
    log local0. "[IP::client_addr] Clairmail persistence HTTP_Response. Set-Cookies: [HTTP::header values Set-Cookie]"
    }
    }
    

    Aaron
  • The second level of testing (a couple of tries with the actual application) is still looking good! Thanks so much Hoolio. It's fun to learn new things (cookies, jseesionid, etc). One thing, I commented out the portion that removes the spoofed cookie. If this gets the program off the ground, I will urge the vendor to change thier code asap so that the mobile application supplies the cookie - I'm guessing that this current fix will be resource intensive when thousands of mobile devices are periodically calling home.
  • Glad to hear that's working for you.

     

     

    The reason I removed the spoofed cookie in HTTP_REQUEST is that I wasn't sure what the app would do if it saw a JSESSIONID in the request which it didn't generate. I figured it was better to not include it in the request to the pool. It wouldn't affect the client sending that cookie in subsequent requests though.

     

     

    Aaron