iRule auth http check

Hi BP,

 

The iRules do not have that type of functionality - not yet at least. There is an indirect technique you can use but it won't be based a triggered event

 

 

Non test example:

 

 

1. Create an HTTP Monitor to monitor the auth PHP Script looking for the return code "200".

 

2. Create a pool called Monitor AUTH_PHPCHECK_POOL which contains the web server(s) that contain the PHP script and associate the HTTP Monitor

 

3. Then you could use the following iRULE on the virtual address that points to the REAL pool.

 

 

when HTTP_REQUEST {
  
    if {[active_members AUTH_PHPCHECK_POOL] = 0 } {

         Log local0. "Redirect accepted because AUTH_PHPCHECK_POOL monitor failed"
      
         HTTP::redirect "http://[HTTP::host]/login.php"

        }

 }

 

 

There are pro's and cons with this. The one con that comes to mind is you can check the auth php in realtime with respect the HTTP Request- since monitors are based on intervals You can lower to 1 second but that usually isn't recommended for monitoring.

 

 

However, if you are looking to redirect any request based on a HTTP STATUS other then 200 then you can do the following

 

 

when HTTP_RESPONSE {
  if { !([HTTP::status] == 200) } {
     HTTP::redirect "http://[HTTP::host]/login.php"
 }
}
This doesn't check the exact PHP script - it simply redirects you based on the website responding back with anything beyond a HTTP STATUS Code of 200.

 

I hope this helps,

 

Bhattman

So there are two options, neither of which are for the novice.

 

 

Option 1, use an APM, It can do the forwading and the login page. Version 10.2.1 is ideal for this. You have 10 free APM licenses. You will have to setup an APM policy with what we call "HTTP auth". It is a bit involved and difficult to describe here but, Devcentral has a lot of information on the APM as well as some examples.

 

 

 

 

Option 2:

 

 

with an I-Rule, allow the request to get to the server un-authenticated. When the server refuses the connection, you capture that in the HTTP_RESPONSE event. Since you are in the HTTP_RESPONSE event, you can then use the HTTP::retry command. This re-run the HTTP Request as if it just came from the client only this time you have set a flag that says "go to the PHP script". The "node" is set to point to your PHP script and the Request is modified to suit the script. You also save the original request in a varialble. When the response from the PHP script comes back, again you would be in HTTP_RESPONSE, this time, you modify the original request so that it is accepted by the server, issue the HTTP::retry again using the modified original request. THis time you have the proper cookie or flag and you will be forwarded normally.

 

 

here is the HTTP::retry page, there are examples:

 

http://devcentral.f5.com/wiki/default.aspx/iRules/HTTP__retry.html

 

 

Also search devcentral for HTTP::retry, there are many examples.

 

HTH

Deb had a fairly in depth example of this in an HTTP::retry article here:

 

 

http://devcentral.f5.com/Tutorials/TechTips/tabid/63/articleType/ArticleView/articleId/105/Conditioning-iRule-Logic-on-External-Information--01--HTTPretry.aspx

 

 

Aaron

"So there are two options, neither of which are for the novice. "

 

 

I disagree. Exactly the kind of project for a novice to become a skilled iRuler.