Forum Discussion

boneyard's avatar
Nov 05, 2013

ACCESS::session remove not working as expected

im trying to invalidate an active APM session by using ACCESS::session remove from the HTTP_REQUEST event. only that specific request is still going through. if i refresh afterwards it fails and redirects me to the policy, so the session was removed (the logs says the same) but the the request in which the ACCESS::session remove is called goes through. same if i perform a HTTP::redirect after the ACCESS::session remove.

 

am i missing something here? what would be the way to invalidate a session for the HTTP request you are performing at that moment.

 

10 Replies

  • Just curious, but what does your iRule look like? The following example should work:

    when HTTP_REQUEST {
        if { [HTTP::uri] equals "/test" } {
            ACCESS::session remove
            HTTP::redirect "http://www.example.com"
        }
    }
    

    You'd necessarily need to issue a redirect if you were removing the session based on request URI, as it'd cause an infinite loop. If you just want to disable the access policy for a particular request, you can use the ACCESS::disable command.

    when HTTP_REQUEST {
        if { [HTTP::uri] equals "/test" } {
            ACCESS::disable
        }
    }
    
  • yeah that is pretty much my iRule. the difference is that i would like to return to the URL i came from and start a new APM session there. which i expected would happen if i just redirect to there.

     

    is that even possible or not going to work due to the delay in the session ending?

     

  • If you're talking about the first example above, that should work with an explicit URL. Are you trying to use the Referer header?

     

  • when HTTP_REQUEST {
        if { [HTTP::uri] equals "/test" } {
            ACCESS::session remove
            HTTP::redirect "/test2"
        }
    }
    

    for example, gives me access to /test2, not the access policy logon screen i expected.

    if would like to redirect to /test but that causes loop issues which im working out now. still to redirect to /test2 is a good example the session isn't closed fast enough.

  • The above iRule should actually work. There may be some latency derived from the size of the access session (AD/LDAP queries?) or overall system stress, but that is interesting indeed. Here's a thought. Change your redirect to an HTTP::respond and expire the MRHSession cookie with a Set-Cookie header. The client should receive a 302, delete the cookie, and come back without the cookie.

     

  • well it seemed to be a version issue, once i upgraded to 11.4.0 it worked directly without having to introduce a wait time. in 11.2.1 (latest hotfix) i experienced above behaviour.

     

    well heading for the next challenge.

     

  • I try to wait with the redirect till the session is removed using the while /after combination. That does the job most of the time.

    when HTTP_REQUEST {
    if { [HTTP::uri] equals "/test" } {
        ACCESS::session remove
        set x [ACCESS::session sid]
    while {[ACCESS::session exists $x]} {
    after 1000
        HTTP::redirect "/test2"
    }
    

    }

  • I try to wait with the redirect till the session is removed using the while /after combination. That does the job most of the time.

    when HTTP_REQUEST {
    if { [HTTP::uri] equals "/test" } {
        ACCESS::session remove
        set x [ACCESS::session sid]
    while {[ACCESS::session exists $x]} {
    after 1000
        HTTP::redirect "/test2"
    }
    

    }

  • I try to wait with the redirect till the session is removed using the while /after combination. That does the job most of the time.

    when HTTP_REQUEST {
    if { [HTTP::uri] equals "/test" } {
        ACCESS::session remove
        set x [ACCESS::session sid]
    while {[ACCESS::session exists $x]} {
    after 1000
        HTTP::redirect "/test2"
    }
    

    }

  • yep after works fine, but as mentioned with newer version you don't need it.