HTTP Redirect

I understand about creating a HTTP redirect and I have the HTML page that we want to forward too all sorted, but my question is can I with iRules forward the first web request of the day for each user to a another site and then not have the page display for another 24 hours?

 

 

You can use the table command to implement your own session tracking (http://devcentral.f5.com/wiki/iRules.table.ashx). You'll need a key/value pair for the table. The key could be the ip address of the client pc or the username (more complex). The value would be a numerical value e.g. 1 (1 == user has ack'ed the policy). There is also a parameter for auto expiration of the table entries (24 hours).

 

 

There are two options

 

 

OPTION 1: table key == IP address of client pc

 

 

This will only work well if users have different IP addresses and those address are the same for at least 24 hours per user. This will not work if the users are working from a terminal server (same ip address for serveral users).

 

 

user1@pc1 --> LB(VS:8080) ---> proxy (IP:8080) ---> Internet

 

 

a.) First Request goes to VS:8080 (the proxy config in their browser)

 

GET http://www.f5.com/

 

 

b.) LB checks if there is a table entry for pc1.

 

iRule commands: [IP::client_addr], table

 

 

c.) If there is an entry, just forward the request to the proxy, as the user has already ack'ed the policy

 

iRule commands: pool

 

 

d.) If there is no entry, use HTTP::redirect to redirect the user to a different webserver (or a VS on the LB). You must include the original URL that has been requested at a.). This is needed for the final redirect (see below).

 

 

iRule commands: HTTP::redirect http://policy.intranet.local/policy.php?url=www.f5.com

 

 

e.) On that server either run some CGI-BIN or PHP or even an iRule (on VS) to present the policy text to the user and check the answer.

 

 

f.) If the user has accepted the policy, send a redirect to the original Site, including some additional information in the URL if the user accepted the policy.

 

 

Redirect: http://www.f5.com/surf_policy_accepted

 

 

g.) At LB check for the URI /surf_policy_accepted. If it's there, remove the string from the URI and send it to the proxy. Then add a record to your table.

 

 

iRule commands: [HTTP::uri] starts_with, table, pool

 

 

Maybe you want to use some form of obfusication or encryption to hide the URL strings from the user.

 

 

 

OPTION 2: table key == username, so we need user authentication

 

 

That's much more complicated, as the proxy will have to authenticate the user. In this scenario, the LB will be placed after the proxy in some sort of "loop"

 

 

user1@pc1 --> proxy --> LB --> proxy (the same) ---> Internet

 

 

a.) First Request to VIP:8080 (the proxy config in their browser)

 

GET http://www.f5.com/

 

 

b.) Proxy requests authentication from the user/browser

 

 

c.) User/browser authenticates and send the first request again

 

 

d.) proxy accepts the authenticated request

 

 

e.) IMPORTANT: The proxy will now forward the request to the LB. It MUST add the username to that request, by adding a HTTP request header, e.d. X-Authenticated-User. Most proxies will be able to do that.

 

 

f.) LB extracts the username and checks if there is a table entry for that username.

 

iRule commands: [HTTP::header], table

 

 

g.) If there is an entry, just forward the request to the second proxy, as the user has already ack'ed the policy. The second proxy could be the same one, however that will require a different policy for requests coming from the LB. As I said, it's much more complicated.

 

 

h.) If there is no entry, use HTTP::redirect to redirect the user to a different webserver (or a VS on the LB). You must include the original URL that has been requested at a.). This is needed for the final redirect (see below).

 

 

iRule commands: HTTP::redirect http://policy.intranet.local/policy.php?url=www.f5.com

 

 

i.) On that server either run some CGI-BIN or PHP or even an iRule (on VS) to present the policy text to the user and check the answer.

 

 

j.) If the user has accepted the policy, send a redirect to the original Site, including some additional information in the URL if the user accepted the policy.

 

 

Redirect: http://www.f5.com/surf_policy_accepted

 

 

k.) At LB check for the URI /surf_policy_accepted. If it's there, remove the string from the URI and send it to the proxy. Then add a record to your table for the username.

 

 

Opviously this is just a rough plan, but I have done similar things with rather large iRules. I implemented the whole user authentication (through a web form) within some iRules and it works quite nicely.

 

 

Hope that helps.

 

 

Regards

 

Kurt Knochner