Invoke another loadbalancer url from current loadbalancer url using irule

Let's look at this from the perspective of "flow". Is the cookiegenerator URL what the client is going to for normal application processing (ie. the website), or is it just a service that must be called to get something before going on to the real website? If the latter, does the client have to make multiple requests to this URL to get what it needs, or is it all done in one request? It would appear from your iRule that this is what you're trying to do, and if so, you would normally add a node command to launch the request off to a given IP address somewhere else, and then an HTTP::retry once that response came back so that you could continue on to the real application. The better option, however, is probably a sideband iRule.

client request -> VIP -> sideband to service -> return from sideband ->             website 

Does that sound like what you need it to do?

Thanks kevin. Following is the usecase. i need to call another serviceurl from current service url for graping the cookie. After graping the cookie return back to current service url. Please add the node command and retry command in the existing code.

I am new to irule, please help me on this.

1) Enter LoadBalancer url http://xmppwst.airservices.eds.com/OAuthDemo/finalusers.html i.e( Actually it is mapped to http://usclspcit192.airservices.eds.com/OAuthDemo/finalusers.html”)

2) Enter userid/password (testuser1/p@ssw0rd)

3) Grab userid/Password(i.e Authorization Header) OR SMCOOKIE

4) Call http://xmppt.airservices.eds.com:8080/TestBasicAuth/cookiegenerator.html with Authorization Header OR SMCOOKIE (Note user shouldn’t it is redirected to 208 box always we need to show loadbalancer url (http://usclssoat208.airsoatest.airservices.eds.com/TestBasicAuth/cookiegenerator.html)

5) Siteminder Authentication returns the Siteminder Cookie

6) AT f5 Grab the SMCookie from 208 box

7) http://xmppwst.airservices.eds.com/OAuthDemo/finalusers.html with SMCookie

Regards, Praque m

Before we get into the details of how to make this work, please clarify a few more things:

1. The user does NOT interact with the cookiegenerator service. The application VIP calls this service with some date, gets some data, then proceeds on with normal program flow. Is that correct?

    

2. If yes to above, are you on a platform that supports sideband? That is a MUCH simpler process than using HTTP::retry.

    

3. Also if yes to above, does this sideband service get called repeatedly, or just once?

    

4. You mention authorization header(assuming from Basic auth) or SMCOOKIE. How would the user already have an SMCOOKIE?

    

Thanks Kevin. Please find my inline comments.

1.The user does NOT interact with the cookiegenerator service. The application VIP calls this service with some date, gets some data, then proceeds on with normal program flow. Is that correct?

praque: yes user does nt interact with cookiegenerator service. application VIP calls cookiegenerator service for grap the cookie and proceeds with the normal flow.

2.If yes to above, are you on a platform that supports sideband? That is a MUCH simpler process than using HTTP::retry. Praque: Not sure whether it supports sideband or not

3.Also if yes to above, does this sideband service get called repeatedly, or just once? Praque : No

4.You mention authorization header(assuming from Basic auth) or SMCOOKIE. How would the user already have an SMCOOKIE? Praque: User need to have either userid/password or SMCookie. Whatever they have, need to send it to cookie generator service. Cookie generator service take care of this validation and return the new smcookie. Grap the new SMCookie and use it in normal flow.

Regards, Praque

Hi Kevin, looks like sideband is disable in environment, i received following error while executing the commands

01070151:3: Rule [SM_USERNAME] error: line 37: [undefined procedure: connect] [connect -timeout 1000 -idle 30 -status conn_status $static::sb_vserver] line 61: [undefined procedure: send] [send -timeout 3000 -status send_status $conn $data] line 81: [undefined procedure: recv] [recv -peek -status peek_status -timeout 10 $conn] line 143: [command is disabled: "close"] [close $conn]

version is 10.2.2

Hi Kevin,

Seems like below code is working. instead of cookiegenerator.html, i used the same html name as default pool(finalusers.html). Please verify the code and advise on this.

when CLIENT_ACCEPTED { log local0. "enter client_accepted"

set gotpath 1 set def_pool [LB::server pool] }

when HTTP_REQUEST {

log local0. "enter http_request: gotpath=$gotpath"

if { $gotpath == 1 } {

            log local0. "inside test_8080"
                    set request_headers [HTTP::request]

                                 log local0. "request_headers::$request_headers"
                                 pool Rachel_test_8080
                                 log local0. "host::[HTTP::host]"

                                 set gotpath 0

  } 
 else {
    log local0. "inside testpool"

      pool $def_pool 
 }
}

when HTTP_RESPONSE {

  log local0. "http_response: cookie=$cookie; status=[HTTP::status]; sm=[HTTP::cookie exists "SMSESSION"];"

if { [HTTP::status] == 200 } { set smsession "SMSESSION=[HTTP::cookie value SMSESSION]" log local0. "smsession:::$smsession"

}

}

Reference: https://devcentral.f5.com/questions/not-returning-back-to-the-current-loadbalancer-url-from-external-service