It is always better to avoid artificial connection processing delays via the iRule after command, unless absolutely necessary. It simply delays results for the client. The idea is for a connection to get set up and complete quickly - in sub-second time (not 20 seconds). In your case, the ACCESS_SESSION_STARTED event occurs at the start of access policy processing, before the policy has produced a result. My guess is you were trying to get around that issue by delaying subsequent iRule command execution. More importantly, F5 recommends using built-in functions rather than an iRule when those built-in function exists. APM already logs access results for each access attempt in its logs. (By default, it writes to /var/log/apm.) You can customize the information that is logged (and where it is logged) but, even in its default configuration, I believe APM produces a more informatory message than what you are trying to write in your example.
Is there a specific reason why you want to write additional log messages that convey a subset of that same information from within an iRule?
If you still want to proceed with the iRule, I believe the issue you are experiencing is related to the timing of the event you have selected, as I mentioned earlier. You might try later events, such as ACCESS_ACL_ALLOWED and ACCESS_ACL_DENIED, which are triggered when a policy allows or denies access for a user. For example:
when ACCESS_ACL_ALLOWED {
if { [HTTP::uri] contains "/login" } {
log local0. 'User [ACCESS::session data get "session.login.last.username"] was allowed by the access policy'
}
}
when ACCESS_ACL_DENIED {
if { [HTTP::uri] contains "/login" } {
log local0. 'User [ACCESS::session data get "session.login.last.username"] was denied by the access policy'
}
}
There are other result parts that you could log, too. This is only an example. Even still, this is duplicating a built-in function.
In general, APM iRule events are typically used to do something the product can't do or to augment the way it behaves. For example, if a policy produces a denied result, you might want to perform a custom check of extenuating circumstances unique to your application delivery that might make you allow access in the end.
As a DevCentral "newbie," might I suggest you take a peek at our free self-paced Getting Started with APM course. In addition, the Configuring BIG-IP APM: Access Policy Manager instructor-led course provides insight on managing access policies with BIG-IP APM.
Altostratus
