Forum Discussion

MattKirkevold_6's avatar
MattKirkevold_6
Icon for Nimbostratus rankNimbostratus
Jun 17, 2011

iRule persitence on uri / payload

I am trying to set persistence using an iRule based on uri. The problem I think I might be having is related to the fact that the first uri that comes through does not contain the persistence string I want to use. When the iRule executes my page fails each time. this site does not use cookies

 

 

the url that contains my sessionid is as such - https://app.domain.com/AppName/con/...8346042343

 

where the 10.100.200.90.1308346042343 string is my sessionid

 

 

the iRule that I have in place (matches, but fails and kills my browser when used is

 

 

when CLIENT_ACCEPTED {

 

set add_persist 1

 

}

 

 

when HTTP_REQUEST {

 

set session_id [lindex [ split [HTTP::uri] "/" ] 3]

 

log local0. "Parsed a webapp sessionid as $session_id"

 

if { $session_id != "" } {

 

persist uie $session_id

 

}

 

}

 

 

 

A little more investigation I find that if I log the session to ltm I see the following sequence before my browser crashes and fails.

 

 

Jun 17 21:47:35 tmm tmm[1710]: Rule webapp-test2 : Parsed a webapp sessionid as

 

Jun 17 21:47:35 tmm tmm[1710]: Rule webapp-test2 : Parsed a webapp sessionid as 10.100.200.90.1308346445866

 

Jun 17 21:47:36 tmm tmm[1710]: Rule webapp-test2 : Parsed a webapp sessionid as 10.100.200.90.1308346445866

 

Jun 17 21:47:36 tmm tmm[1710]: Rule webapp-test2 : Parsed a webapp sessionid as 10.100.200.90.1308346445866

 

Jun 17 21:47:36 tmm tmm[1710]: Rule webapp-test2 : Parsed a webapp sessionid as 10.100.200.90.1308346445866

 

 

Interesting to note is that the first URI match is blank as it come from a dfferent pattern

 

https://app.domain.com/AppName/com?...tion=relay

 

and contains the session id in the body of the page itself

 

Jun 1HTTP/1.1 200 OK

 

Date: Fri, 17 Jun 2011 21:47:24 GMT

 

Server: Apache-Coyote/1.1

 

RS-ID: FD4970736D89CFBECC8C54DD3F398DC3

 

Content-Type: text/plain

 

SafeWord-SSL: yes

 

Transfer-Encoding: chunked

 

8d

 

Relay Parameter

 

Fri Jun 17 15:34:06 MDT 2011

 

maxpollinterval=6000

 

sessionid=10.100.200.90.1308346445866

 

pollincreasefactor=4

 

protocol=http

 

0

 

but does not contain the sessionid as being pull using the lindex split. Perhaps I need to throw that URL out somehow before capturing the string in the iRule, but how if so correct?

 

 

Any help is greatly appreciated

 

 

 

 

 

 

 

 

 

 

4 Replies

  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus

     

    As a quick response (Sorry, need to digest your question and think about it a bit)...

     

     

    Just because the site doesn't use cookies doesn't mean you can't use session cookies yourself for session persistence... The Session cookies are INSERTED into the response. And the backend isn't actually involved in them at all.

     

     

    Let me think about the rest just in case you really really don't want to, or can't use (Not a browser?) active cookies for persistence.

     

    H
  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    OK...

     

     

    I'm not sure why your browser crashes and fails... What your doing doesn't seem (To me) to be bad... The first request doesn't get persisted... The second does... But it's apparently not a problem with persistence that causing your browser failure, because I'd expect that to exhibit as an unknown session for the second access (If the client was balanced to the wrong poolmember for example).

     

     

    Myself, I usually always tend to use active cookies for persistence... I haven't yet seen an instance (For a browser) where it isn't possible to use a cookie... For other protocols, I've used various things. e.g. LDAP...

     

     

    For the life of me I can't see why anything the iRUle does would crash your browser... If the browser crashes because of bad input, then it's a problem with the browser... That;s a bug in the browser pure & simple... (And usually indicative of a security vulerability... At the least a DOS vuln... If it can be exploited, then it's even worse).

     

     

    What browser is it? If IE< does using firefox make a difference? What about chrome or Safari?

     

     

     

    H

     

  • Hamish,

    Thanks for the replies, greatly appreciated.

    I think part of this is related to the browser starting a java applet (more info to me) and that session is what needs to persist. This would crash out either FF or IE. I did a birt more research and was also pointed to the following that did the trick.

    http://devcentral.f5.com/Tutorials/TechTips/tabid/63/articleType/ArticleView/articleId/160/iRules-persist-v-persist-add.aspx

    By setting the pesist add is the RESPONSE section I was able to then use the general persist in the REQUEST. Because the REQUEST and RESPONSE have difference in representing the sessionid I used 2 different mthods to retrieve the sessionid. This tested out and worked.

    
    when CLIENT_ACCEPTED {
       set add_persist 1
    }
    
    when RULE_INIT {
      set ::debug 0
    }
    
    when HTTP_REQUEST {
    set cli [IP::remote_addr]:[TCP::remote_port]
    set session_id [lindex [ split [HTTP::uri] "/" ] 3]
    if {$::debug}{log local0. "Client: $cli  Request session_id: >$session_id<"}
      if {$session_id != "" } {
          persist uie $session_id
      }
    }
    
       when LB_SELECTED {
    if {$::debug}{log local0. "Client: $cli  LB to:  [LB::server addr]"}
    }
      when HTTP_RESPONSE {
    HTTP::collect 1
    set parse [ findstr [HTTP::payload] sessionid= 10 ]
    set session_id [split [lindex [split $parse] 0] " "]
    if {$::debug}{log local0. "Client: $cli  Request session_id: >$session_id<"}
      if { $session_id != "" and $add_persist == 1 } {
          persist add uie $session_id
      }
    }
    

    -Matt
  • If you have users connecting from behind the same proxy, you might get more than one session per TCP connection. If that's the case, then you'd probably want to check each response for a new session ID versus doing this just once per connection.

     

     

    Also, if you're on a CMP capable platform and OS version, you should replace the global debug variable with a local one set in CLIENT_ACCEPTED to avoid CMP being disabled:

     

     

    http://devcentral.f5.com/wiki/default.aspx/iRules/CMPCompatibility.html

     

     

    Aaron