http_header("Authorization")

Hello,

What are the symptoms of the failure? To troubleshoot non-cookie persistence issues, you can check the persistence records via the GUI under Overview >> Statistics >> Persistence Records or via the CLI (using: watch -n1 'b persist all show all').

You might want to check to see if there is a value for the Authorization header before using the value of the header for persistence:

when HTTP_REQUEST {
   if {[string length [HTTP::header value "Authorization"]]}{
      persist uie [HTTP::header value "Authorization"]
      log local0. "[IP::client_addr] -> [HTTP::host][HTTP::uri] had Authorization header value: \
         [HTTP::header value "Authorization"]"
   }
}

Aaron

The symptoms of the failure were that user sessions were being switched back and forth between the pool members instead of staying on the original server they were connected to. I have run a tcpdump and verified that the Authorization header is present. At this time we’re just using simple IP source persistence, but this could soon become a problem as a lot of users go through proxies and appear to come from the same IP.

 

 

You could try adding fallback persistence profile specifying simple/source address persistence to catch any instances in which the auth header is not consistent.

 

 

hth

 

/deb

Good point, Deb. With just the UIE persistence, I would imagine that the client first makes a request without the credentials, so they'd get lumped together with all other clients who make such a request. Then when they make a new request with credentials, they'd get load balanced to a new member and get a new persistence record.

 

 

Aaron

Posted By hoolio on 02/04/2008 2:45 AM

Hello,

What are the symptoms of the failure? To troubleshoot non-cookie persistence issues, you can check the persistence records via the GUI under Overview >> Statistics >> Persistence Records or via the CLI (using: watch -n1 'b persist all show all').

You might want to check to see if there is a value for the Authorization header before using the value of the header for persistence:

 
 when HTTP_REQUEST { 
 if {[string length [HTTP::header value "Authorization"]]}{ 
 persist uie [HTTP::header value "Authorization"] 
 log local0. "[IP::client_addr] -> [HTTP::host][HTTP::uri] had Authorization header value: \ 
 [HTTP::header value "Authorization"]" 
 } 
 } 
 

Aaron

Hi, I have just found this post today and I am running into an issue on v10.0.1 which is related to this.

The problem I have is that we have a v4 box which persists an application using the expression method and works fine:

http_header("Authorization")

Now that we have the new v10.0.1 boxes I have tried your rule above and persistence is simply not working.

Running a trace I see that some of the client requests don't have the Authorization header and this would explain why it's not working on v10.0.1, but this works on v4 as it is.

Is it possible that v4 used to check outside of the header, ie the body of the message?

If so how could this be done and used in a uie persistence iRule?

Thanks for any help.

As Deb suggested it would make sense to use source address persistence as a fallback method. If you're still seeing issues, then I'd still suggest using the same troubleshooting steps:

To troubleshoot non-cookie persistence issues, you can check the persistence records via the GUI under Overview >> Statistics >> Persistence Records or via the CLI (using: watch -n1 'b persist all show all').

You can add logging to the iRule as well to get a better idea of what's happening:

 
 when HTTP_REQUEST { 
    log local0. "[IP::client_addr]:[TCP::port]: Request to [HTTP::host][HTTP::uri] had Auth header value: \  
       [HTTP::header value "Authorization"], with persistence record: [persist lookup uie [HTTP::header value "Authorization"]]"  
  
    if {[string length [HTTP::header value "Authorization"]]}{  
       persist uie [HTTP::header value "Authorization"]  
    }  
 } 
 

Aaron

Hi,

 

 

Rather than persisting on "Authorization" header I have used:

 

 

persist uie [HTTP::username]

 

 

This is kind of the same thing (Authorization would retun a b64 encoded username and password) and works for our app.

 

 

I would suggest that people who used to persist on http_header("Authorization") in v4 try this in v9 / v10.

 

 

Thanks for you help, really good logging example.

As you mention, HTTP::username is just parsed from the Authorization header by base64 decoding the value and splitting the user:pass on the colon. I'm not sure how using HTTP::username would work if using the full Authorization header wasn't working (assuming the user wasn't changing their password between every request).

 

 

Aaron

We used something like this:

 

 

when HTTP_REQUEST {

 

 

if { [HTTP::username] ne "" and [HTTP::username] ne "user" } {

 

persist uie [HTTP::username]

 

} else {

 

HTTP::respond 401 noserver WWW-Authenticate "Basic realm=\"All\"" Server "IBM_HTTP_Server" Vary "Accept-Encoding" Keep-Alive "timeout=15, max=100" Content-Type "text/plain" Content-Language "en-us"

 

}

 

}