Forum Discussion
MattKirkevold_6
Nimbostratus
NimbostratusiRule 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
8d
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
HamishCirrocumulus
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- HamishOK...
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 
MattKirkevold_6Hamish,
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
hooleylistCirrostratus
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