Forum Discussion
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.