[ProxyPass_v10.3] Bypass Cookie rewriting

Hi Pierre,

 

 

You could just remove lines 397 - 445 of ProxyPass to fix this. If you're never going to use ProxyPass on two different domains, you don't need this code and will save some complexity and resources by removing it.

 

 

Alternatively, you could modify ProxyPass to not rewrite the cookies if the external and internal domains are the same.

 

 

Aaron

I use ProxyPass for multiple domains and I also use it in cases where cookie rewriting is needed so I was looking for a way to do all this with only one iRule to ease the management.

 

 

I'll just copy ProxyPass to a ProxyPassNoCookies and remove the lines about cookie rewriting for now but I might have to implement some options one day if I need more flexibility.

 

 

Thanks for your answer!

I have a similar issue where the cookie portion is "chopping" up my home-grown cookie (splitting on a colon(:) in the cookie) . How would I modify proxypass to NOT rewrite if the external and internal domains are the same?

 

 

 

 

 

 

 

 

 

Hi Mark,

 

 

Can you enable debug and copy a few anonymized examples of these log lines from /var/log/ltm?

 

 

log local0. "Modifying cookie $cookiename domain from $elementvalue to $host_clientside"

 

log local0. "Modifying cookie $cookiename path from $elementvalue to $path_clientside[substr $elementvalue [string length $path_serverside]]"

 

log local0. "Inserting cookie: $cookielist($cookiename)"

 

 

Thanks, Aaron

I am actually not seeing a Modifying cookie statement in the log but I do see lots of "inserting cookie"

 

 

 

Here is an example: ProxyPass V8.2

 

 

 

Aug 8 11:37:00 tmm tmm[1706]: Rule ProxyPass82_lms_logging : lh-stage.xxx.com, Host=lh-stage.xxx.com, URI=/lmsSupport/setCookie.htm: Looking for entries matching lh-stage.xxx.com/lmsSupport/setCookie.htm

 

Aug 8 11:37:00 tmm tmm[1706]: Rule ProxyPass82_lms_logging : lh-stage.xxx.com, Host=lh-stage.xxx.com, URI=/lmsSupport/setCookie.htm: Found Rule, Client Host=lh-stage.xxx.com, Client Path=/lmsSupport, Server Host=pine-stage.xxx.com, Server Path=/lmsSupport

 

Aug 8 11:37:00 tmm tmm[1706]: Rule ProxyPass82_lms_logging : lh-stage.xxx.com Host=lh-stage.xxx.com, URI=/lmsSupport/setCookie.htm: New Host =pine-stage.xxx.com, New Path=/lmsSupport/setCookie.htm

 

Aug 8 11:37:00 tmm tmm[1706]: Rule ProxyPass82_lms_logging : lh-stage.xxx.com, Host=lh-stage.xxx.com, URI=/lmsSupport/setCookie.htm: Using parsed pool stagefarm

 

Aug 8 11:37:01 tmm tmm[1706]: Rule ProxyPass82_lms_logging : Inserting cookie: 1312817818

 

Aug 8 11:37:01 tmm tmm[1706]: Rule ProxyPass82_lms_logging : Inserting cookie: zj7Yu6AbX7YowrdTy0CnqGIn6sZERx1aKOqGJnU; domain=xyz.com; path =/

 

Aug 8 11:37:01 tmm tmm[1706]: Rule ProxyPass82_lms_logging : Inserting cookie: XYZCOOKIE=xxxx@junk.xxx.com

 

 

 

The actual cookie looks like this:

 

HTTP: Cookie: XYZCOOKIE=xxx@xxx.xyz.com:1312817818:zj7Yu6AbX7YowrdTy0CnqGIn6sZERx1aKOqGJnU; path=/; domain=.xyz.com;

 

 

 

Would this work?

 

 

Rewrite any domains/paths in Set-Cookie headers

 

if {[HTTP::header exists "Set-Cookie"]}{

 

array set cookielist { }

 

A response may have multiple Set-Cookie headers, loop through them

 

foreach cookievalue [HTTP::header values "Set-Cookie"] {

 

set cookiename [getfield $cookievalue "=" 1]

 

set newcookievalue ""

 

 

New check for XYZCOOKIE

 

if {$cookiename eq "XYZCOOKIE"} {

 

if {$::ProxyPassDebug > 1} {

 

log local0. "Skipping XYZ cookie $cookiename"

 

}

 

skip to the next iteration of this loop

 

continue

 

} end XYZ check

 

 

Each cookie starts with name=value and then has more name/value pairs

 

foreach element [split $cookievalue ";"] {

 

set element [string trim $element]

 

if {$element contains "="} {

 

set elementname [getfield $element "=" 1]

 

set elementvalue [getfield $element "=" 2]

 

 

if {$elementname eq "domain"} {

 

Rewrite domain of cookie, if necessary.

 

if {$elementvalue eq $host_serverside} {

 

if {$::ProxyPassDebug > 1} {

 

log local0. "Modifying cookie $cookiename domain from $elementvalue to $host_clientside"

 

}

 

set elementvalue $host_clientside

 

}

 

}

 

if {$elementname eq "path"} {

 

Rewrite path of cookie, if necessary.

 

if {$elementvalue starts_with $path_serverside} {

 

if {$::ProxyPassDebug > 1} {

 

log local0. "Modifying cookie $cookiename path from $elementvalue to $path_clientside[substr $elementvalue [string length $path_serverside]]"

 

}

 

set elementvalue $path_clientside[substr $elementvalue [string length $path_serverside]]

 

}

 

}

 

append newcookievalue "$elementname=$elementvalue; "

 

} else {

 

append newcookievalue "$element; "

 

}

 

}

 

Store new cookie value for later re-insertion. The cookie value

 

string will end with an extra "; " so strip that off here.

 

set cookielist($cookiename) [string range $newcookievalue 0 [expr {[string length $newcookievalue] - 3}]]

 

}

 

Remove all Set-Cookie headers and re-add them (modified or not)

 

HTTP::header remove "Set-Cookie"

 

foreach cookiename [array names cookielist] {

 

HTTP::header insert "Set-Cookie" $cookielist($cookiename)

 

if {$::ProxyPassDebug > 1} {

 

log local0. "Inserting cookie: $cookielist($cookiename)"

 

}

 

}

 

}

 

}

 

That looks like it should work. Which LTM version are you running this on? For LTM v10 or higher, you should use the ProxyPassV10 rule:

 

 

http://devcentral.f5.com/wiki/iRules.proxypassv10.ashx

 

 

Aaron

Running 9.4.8 still...so I am using ProxyPass82....I will let you know how my testing goes....

 

 

Can you see any reason why the iRule would be messing with the cookie? especially splitting it up on the colon (:)??

 

 

--mark

Hmmmm...It looks like my problem may be this: The fix is to move to v10 TMOS code --- Are patches available without updating the entire OS??

 

 

====================================================

 

 

http://support.f5.com/kb/en-us/solutions/public/8000/600/sol8676.html?sr=15917538

 

 

HTTP::header values and colons in multiple headers (CR98328)

 

The HTTP::header values use a colon ( : ) character internally to separate multiple header values being returned. Because of this, when the resulting concatenated string is split into a Tcl list object, colons that are embedded in the content are removed, and the value is split at the colon location. This occurs only on multiple headers. The workaround is to make sure your content contains no colons when you are using multiple headers.

Nice work in finding that known issue. I don't believe a hotfix was ever created for 9.4.x, but you could open a case with F5 Support and see if one was created.

 

 

9.4.8 will be at the end of software development in Dec with only security fixes being continued until Aug 2012. So it's not a bad time to upgrade to 10.x anyhow :)

 

 

sol5903: BIG-IP software support policy

 

http://support.f5.com/kb/en-us/solutions/public/5000/900/sol5903.html

 

 

Aaron