Priority Group Activation Failback with HTTP Cookie Insert
Hello All, Can someone help me the below issue? We have a pool with 3 members. 2 members have high priority (Round Robin) and 1 member has low priority. When both the primary members go down, the low priority member should take over the traffic. We have Cookie Insert persistence enabled on the virtual server. In Cookie persistence, "Expiration: Session Cookie" enabled. When both the primary members were made down, the low priority member took over the traffic. When both the primary members came back UP, the traffic continued to go to low priority backend member. When the browser tab is closed and tried to access the URL in new tab, the traffic went to low priority backend member. When the browser window is closed and tried to access the URL in new tab, the traffic still went to low priority backend member. When the browser cookies were deleted and tried to access the URL in new tab, the traffic was taken over by the high priority members. This behavior is not desired and we need to force the LB to use high priority backend members as soon as they come UP. When user tries the connection from new browser or new tab, the traffic should go to high priority pool members. Please let me know how i can achieve the desired behavior. Regards
Remove Cookie from Request Based on Cookie Domain
I have a web application that will fail if it sees any cookies other than what it knows should be present. I need to scrape/remove all cookies other than that which is required. The required cookie has a semi-dynamic name that could be partially shared with cookies that we do not want. Thus I'm focusing on the cookie domain which I know will be unique. Below is my attempt to complete this. The reason I am not working on the http response is that the other cookies on the client may be required for other applications so I just have to allow only the cookie of interest on the incoming (Request) traffic. The problem I am currently having is that the cookie domain appears to be empty for every incoming cookie. The logging is working properly, but the rule is removing every cookie because the 'cookiedomain' variable is empty. If I change the step 2 logging to "[HTTP::cookie domain $cookie]" it still is blank when outputting the cookie domain. Any help identifying why I am not properly capturing the cookie domain would be much appreciated. when HTTP_REQUEST { set cookies [HTTP::cookie names] foreach cookie $cookies { log local0. "step 1 - cookie name is $cookie" set cookiedomain [HTTP::cookie domain $cookie] log local0. "step 2 - cookie domain is $cookiedomain" if { $cookiedomain ne "test.mysite.org" }{ log local0. "step 3 - Removing cookie $cookie" HTTP::cookie remove $cookie } } }Looking for Feedback/Efficiency on Cookie Removal
Background: We have a homegrown portal that users log in to and then launch applications from. This portal injects a ridiculous number of cookies into the client. One or more of these cookies prevent an application from working correctly. My iRule that I quickly made to 'fix' the issue is below. Since I cannot modify the response to expire the cookies I don't want since that will break other applications if they attempt to launch them, I have to scrub any of the cookies I don't want to get to this application on every incoming request. Question(s): 1) Aside from fixing the portal (I want to replace it with APM...we'll see) is there another avenue I should be looking at to fix this besides an iRule? 2) Can my iRule be made more efficient through using switch or data groups? I couldn't figure out how to do that since I don't know of a way to do 'not equal' or not 'starts_with' within switch or how to get the data group syntax to work. There are more cookies I have to allow than included here. I shortened it. when HTTP_REQUEST { set cookies [HTTP::cookie names] log local0. "Inbound cookies are $cookies" foreach cookie $cookies { if { !($cookie starts_with "f5" or $cookie starts_with "" or $cookie starts_with "") }{ HTTP::cookie remove $cookie log local0. "Removing cookie $cookie" } } }
Bypass caching when a cookie matching a pattern is present
We have created an iRule which should disable caching for any request containing a cookie matching a pattern (starting with SESS). It seems like all the rules we have tried have no effect. When caching is enabled for the pool, requests are always cached. Here is the latest rule we have: when HTTP_REQUEST { set c_cookies [HTTP::cookie names] if {[lsearch -regexp $c_cookies "SESS*"]} { CACHE::disable } } Any ideas on why this wouldn't be working? Also, I'm curious if F5's respect the HTTP Cache-Control max-age header.
Invalidate cookie on klient side
Hi, I have an issue with a client cookie that are causing some issues. To avoid pushing out a new application deploy in production I like to do a fix in the BigIP until we have the next maintenance where the application is patched. I found an example in this forum that I have modified. The cookie I like to modify exists in two different versions with the same name. So I need to check some parameters in the cookie to make sure that its the correct cookie. Name: METRICS Domain: .bar.com Path: / I have this iRule that I have one issue with. With I try to do a match class to the Path to be "/" I get the following error: 01070151:3: Rule [/Common/METRIC-cookie] error: Unable to find value_list (/) referenced at line 4: [class match [HTTP::cookie "Path"] eq "/"] when HTTP_REQUEST { Check the User-Agent string if { ([HTTP::cookie exists "METRICS"] && [class match [HTTP::cookie "Domain"] eq ".bar.com"] && [class match [HTTP::cookie "Path"] eq "/"])} { Set a variable to check the cookie in the response set check_cookie 1 } else { Set a variable to check the cookie in the response set check_cookie 0 } } when HTTP_RESPONSE { Check if cookie exists if { $check_cookie && [HTTP::cookie exists "METRICS"]}{ Update cookie expiry time HTTP::cookie expires METRICS 1388534400 } }
list element in quotes followed by <something> instead of space
The following iRule occasionally produces errors: foreach cookie [HTTP::cookie names] { switch -glob -- $cookie { "xxxxx" - "xxxx" - "xxxx" - "xyxyxyx" - "xxyxyx" - "xyxyxy*" { HTTP::cookie remove $cookie } } } } I was scrolling through logs and noticed this: - list element in quotes followed by "de25df2-103438293-"" instead of space while executing "foreach cookie [HTTP::cookie names] { switch -glob -- $cookie { "xxxxx" - "xxxx" - "xxx" - "xxxx" - "xxx" - "xxxxxxx" { ..." Initially I tried to use the catch command to prevent execution failures. Mostly I wanted to see the cookie name. I wasn't able to figure out where to place it, however, as the error seems to fire on the line that initiates the switch. I was able to prevent this error form occurring by doing the following, but it seems less efficient. when HTTP_REQUEST { set cookies [HTTP::cookie names] set cookie_list [split $cookies " "] foreach cookie $cookie_list { switch -glob -- $cookie { "xxxx" - "xxxxx" - "xxxxx" - "xxxx" - "xxxx*" - "xxxxxx*" { HTTP::cookie remove $cookie } } } } I would like to understand how to catch the error, or figure out why the native [HTTP::cookie names] list doesn't parse well unless I split it out specifying the " " character.specific pool member based on URI reruns causing failure
I have an iRule that runs to allow me to test a specific pool member provided I put a special word in the uri; the application is a java app, and the Java part works fine. The problem is when the application comes back to run a report, it changes the uri and the HTTP_REQUEST runs again putting me in the wrong pool. I thought the cookie would prevent this from happening, but it's not. Here's the code when HTTP_REQUEST { if {not [HTTP::cookie exists "admintest"]} { if {[string tolower [HTTP::uri]] ends_with "admin"} { pool Test_Pool member 192.168.2.100:80 ; log local0. "WELCOME [HTTP::uri]" } else { pool TEST_Pool member 192.168.2.200:80 ; log local0. "This is not the right place" } } } when HTTP_RESPONSE { HTTP::cookie insert name "admintest" value "IamTesting" }
Cookies with Duplicate Names, but different values not getting Secure and HttpOnly attributes set
We had an ASV scan come back with one of our applications not setting the Secure and HttpOnly attributes. When they set at the application layer it seems to break their SSO functionality. We are digging into that, but in the meantime, we are using the following iRule to add Secure and HttpOnly attributes. It works; however I noticed that the application has two cookies they are sending with identical names, but different values. For one reason or another, the first cookie with the same name gets the attributes and the second is ignored. We are exploring if the application team needs these and if not we can remove them; however, until then I'm trying to see if anyone else has had this issue or thoughts on a solution. https://support.f5.com/csp/article/K84048752 when HTTP_RESPONSE { foreach mycookie [HTTP::cookie names] { set ck_value [HTTP::cookie value $mycookie] set ck_path [HTTP::cookie path $mycookie] HTTP::cookie remove $mycookie HTTP::cookie insert name $mycookie value $ck_value path $ck_path version 1 HTTP::cookie secure $mycookie enable HTTP::cookie httponly $mycookie enable } } /jeffLightboard Lessons: What are Website Cookies?
When you visit a website today, you might notice a banner that pops up and says something like...This website uses cookies, and you have to accept them to make the site work properly. But, do you know what a "cookie" is? Or, what it is used for? This lightboard lesson digs into the detail of website cookies, so check it out to learn more!
