iRule To Test Webpage Login

This could be done with something like a sideband call, but not sure that'd be very efficient, considering you'd be making this "pre-check" on every access to the logon page. Have you considered, perhaps, an external monitor and cURL script?

I'd suggest doing this with a monitor rather than an iRule. Is there a reason that's not an option?

You can do almost anything with a cURL script that you can do with a browser, short of JavaScript execution. A forms-based logon page is really nothing more than a POST method to the server with a payload. If you can capture the browser-side interaction, with something like Fiddler or HTTPWatch, you can usually mimic this behavior in script. If you can post this capture to the thread we should be able to help you build the cURL script as well.

Sorry Kevin but...

You can avoid the added complexity of a cURL script and a monitor could still be the better choice depending on the authentication method used. What is it?

Extract the Fiddler capture to a text file and scrub user/pass information. What's important is the context of the transaction.

Request header POST /login.aspx?ReturnUrl=%2f HTTP/1.1

Text View Below is what gets me into the webpage.

__EVENTTARGET=&__EVENTARGUMENT=&__VIEWSTATE=%2FwEPDwUJMzIxMjI5MTcyD2QWAgIBD2QWAgIBDxYGHgRocmVmBSdBcHBfVGhlbWVzLzIwMDgvTWFzdGVyQWxsU3R5bGVTaGVldC5jc3MeBHR5cGUFCHRleHQvY3NzHgNyZWwFCnN0eWxlc2hlZXRkZHoU5PbFayHeS3YXna6AC3KkcHrCpXtzLfgNlq23FQjJ&__EVENTVALIDATION=%2FwEWBAK9wNu%2BBwLG%2BZuPDwK238z2DgLEg7eLCwzMmipeemHJGihtGgBvgaxvjdWcM25DHKW7ZpZcGPV0&loginControl%24UserName=fakeuser&loginControl%24Password=fakepassword&loginControl%24LoginButton=Log+In

The ViewState and EventValidation bits may present a problem, but let's start with a little test. From the BIG-IP command line:

curl -v http://www.example.com/login.aspx?ReturnUrl=/ -d "loginControl%24UserName=fakeuser&loginControl$Password=fakepassword&loginControl$LoginButton=Log+In"

** change the "fakeuser" and "fakepassword" to real values.

Did you capture good and bad auth in Fiddler for comparison?

I ended up running the command below and it seemed to login and return different output. I ran the command a second time and received an Invalid Viewstate error with the F5's ip address in the output. This OK because it still returns a 302 redirect code. I've seen the same Viewstate error from Chrome due to some cookie bug in the browser so Im pretty this command worked. Now I need to be able to put this into a health monitor so it monitors each web server instead of going to the public ip address which is what the cURL command is doing. I feel like the below is capturing encrypted information that might change? The monitor that I configure should stay up as long as it receives a 302 code.

curl -v https://example.com/login.aspx?ReturnUrl=/ -d "__EVENTTARGET=&__EVENTARGUMENT=&__VIEWSTATE=%2FwEPDwUJMzIxMjI5MTcyD2QWAgIBD2QWAgIBDxYGHgRocmVmBSdBcHBfVGhlbWVzLzIwMDgvTWFzdGVyQWxsU3R5bGVTaGVldC5jc3MeBHR5cGUFCHRleHQvY3NzHgNyZWwFCnN0eWxlc2hlZXRkZFOobZPm9K3a4hO1RnWM33CEyppfhZZNi7oOQn5FTVQm&__EVENTVALIDATION=%2FwEWBALpwI7uBQLG%2BZuPDwK238z2DgLEg7eLCxcPmUfclikGHAdQZaZkRGQ0k287r7t9ulIfYyTL3%2Fv5&loginControl%24UserName=fakeusername&loginControl%24Password=fakepassword3&loginControl%24LoginButton=Log+In"

So you're getting what you expect even with an invalid ViewState? And a 302 indicates a good auth? What does a bad auth do?

This is preliminary, but here's a slight modification to the sample external monitor in /config/monitors/sample_monitor:

!/bin/sh

 these arguments supplied automatically for all external pingers:
 $1 = IP (::ffff:nnn.nnn.nnn.nnn notation or hostname)
 $2 = port (decimal, host byte order)
 $3 and higher = additional arguments

pidfile="/var/run/$MONITOR_NAME.$1..$2.pid"

if [ -f $pidfile ]
then
    kill -9 -`cat $pidfile` > /dev/null 2>&1
fi

echo "$$" > $pidfile

node_ip=`echo $1 | sed 's/::ffff://'`

response=`curl -s http://$node_ip:$2/redir.php -d "test=1234&foo=bar" -w "%{http_code}"`

if [ $response -eq 302 ]
then
    rm -f $pidfile
    echo "up"
fi

rm -f $pidfile

This simply looks at the return code (302) from the response. It can, and probably should be more elaborate that this.

Where does the logon page get the ViewState value by the way?