Forum Discussion

Algebraic_Mirror's avatar
Algebraic_Mirror
Icon for Cirrostratus rankCirrostratus
Jun 03, 2019
Solved

Is "ACCESS::session remove" an asynchronous iRule command?

I'm having an issue with an iRule I'm writing. I'm trying to delete an access session as soon as I see a certain condition. I am using this command:

 

ACCESS::session remove -sid [HTTP::cookie value "MRHSession"]

 

Unfortunately, it doesn't seem to remove the session immediately. The iRule finishes and the user gets to the next page on the site, but if I look in the Active Sessions screen that session is still there. But then, a minute or so later, that session will disappear (and it does not disappear based on idle timeout, which is one hour, or max timeout, which is like a week). I can only conclude the iRule command is finally killing it off, but much later than when I actually ran it. Is this an asynchronous call or something that can't be guaranteed to have happened at the time command finishes executing?

APM
iRules
security
  • Algebraic_Mirror's avatar
    Algebraic_Mirror
    Jun 05, 2019

    Looks like another engineer I work with may have found the answer. The command is behaving differently than when I used it in the past (versions 12 and below) but not necessarily because it's asynchronous. It looks more likely that it's simply failing to process in a timely fashion due to this Bug ID. I am calling it in the HTTP_REQUEST event, which is outside the ACCESS events, and my version is 13, which is affected. So it looks like I meet the criteria to hit the bug.

     

    I've decided to try to work around this by simply deleting the user's MRHSession cookie (this is the name of APM's session cookie) during the next HTTP response, which has the effect of killing off their access to the session, while allowing them to keep browsing to unprotected areas of the site. Hopefully this information and the workaround will be of use to others who may run into this bug.

     

     

    Bug ID 697590: APM iRule ACCESS::session remove fails outside of Access events

    Known Affected Versions:

    13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5, 13.1.0.6, 13.1.0.7, 13.1.0.8, 13.1.1, 13.1.1.1, 13.1.1.2, 13.1.1.3, 13.1.1.4, 13.1.1.5, 14.1.0, 14.1.0.1, 14.1.0.2, 14.1.0.3, 14.1.0.4, 14.1.0.5, 15.0.0

    Opened: Dec 05, 2017

    Severity: 3-Major

    Symptoms

    ACCESS::session remove fails

    Impact

    APM iRule ACCESS::session remove fails to remove session

    Conditions

    iRule calling ACCESS::session remove outside of Access events.

    Workaround

    Use "ACCESS::session modify" and set the timeout/lifetime to something small, like 1 second. This should cause the session to be deleted due to timeout almost immediately, but note that it will show up in logs as timeout.

    Fix Information

    None

     

3 Replies

Sort By
  • Stanislas_Piro2's avatar
    Stanislas_Piro2
    Icon for Cumulonimbus rankCumulonimbus
    Jun 03, 2019

    Hi,

     

    recommended solution to disconnect user is to redirect to /vdesk/hangup.php3

     

    the user will be redirected to logout page

  • Algebraic_Mirror's avatar
    Algebraic_Mirror
    Icon for Cirrostratus rankCirrostratus
    Jun 05, 2019

    The hangup page is not really a substitute for the iRule command. The hangup page is used when you want the user to log out, and you want to send them an actual logout page and basically stop the flow of all their traffic.

     

    The iRule "ACCESS::session remove" command is used for very different use cases. It is used when you want to end a session based on some condition you see in the traffic, but you don't want to interrupt the flow of the user's browsing by redirecting them and stopping them cold on the logout page. That's the scenario I'm in, so calling the logout page would not be an acceptable substitute.

  • Algebraic_Mirror's avatar
    Algebraic_Mirror
    Icon for Cirrostratus rankCirrostratus
    Jun 05, 2019

    Looks like another engineer I work with may have found the answer. The command is behaving differently than when I used it in the past (versions 12 and below) but not necessarily because it's asynchronous. It looks more likely that it's simply failing to process in a timely fashion due to this Bug ID. I am calling it in the HTTP_REQUEST event, which is outside the ACCESS events, and my version is 13, which is affected. So it looks like I meet the criteria to hit the bug.

     

    I've decided to try to work around this by simply deleting the user's MRHSession cookie (this is the name of APM's session cookie) during the next HTTP response, which has the effect of killing off their access to the session, while allowing them to keep browsing to unprotected areas of the site. Hopefully this information and the workaround will be of use to others who may run into this bug.

     

     

    Bug ID 697590: APM iRule ACCESS::session remove fails outside of Access events

    Known Affected Versions:

    13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5, 13.1.0.6, 13.1.0.7, 13.1.0.8, 13.1.1, 13.1.1.1, 13.1.1.2, 13.1.1.3, 13.1.1.4, 13.1.1.5, 14.1.0, 14.1.0.1, 14.1.0.2, 14.1.0.3, 14.1.0.4, 14.1.0.5, 15.0.0

    Opened: Dec 05, 2017

    Severity: 3-Major

    Symptoms

    ACCESS::session remove fails

    Impact

    APM iRule ACCESS::session remove fails to remove session

    Conditions

    iRule calling ACCESS::session remove outside of Access events.

    Workaround

    Use "ACCESS::session modify" and set the timeout/lifetime to something small, like 1 second. This should cause the session to be deleted due to timeout almost immediately, but note that it will show up in logs as timeout.

    Fix Information

    None