PERSIST at the pool level only

There is no default command to bail out of an entire iRule. The way I usually do this is set a variable early in the iRule and then check that to see if I need to process certain portions.

 

 

Colin

Initially based on client IP and then a secondary check of a logon token that we look up server side to see who it is. We don't generate the logon token so we have to already make a call out to the auth system to verify the token for each request...we just add the logic to make sure we're on the right side.

 

 

The client ip is an application proxy that lives at each client location to route traffic over a private WAN. We know who has what IPs, but may not have the most recent list when a new/additional one is added. So we use a security module on the web tier to identify and validate the user (auth token)/client to the web pool/stack processing the request (a guarrantee we are on the correct stack). If it fell through to the wrong pool, we reject, then attempt to catch the response in the iRule and re-send the request to the other side, adjusting the session cookie as needed so the next request followes to the correct pool, and the user doesn't know it even happened...unless something went haywire and then the reject would make it back to the desktop with a HTTP 307 to the same URL/POST and it gets corrected on the redirect/retry.