Forum Discussion
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
- Kevin_Stewart
Employee
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?
- Kevin_Stewart
Employee
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.
- Kevin_Stewart
Employee
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.
- Juerg_Wiesmann
Nimbostratus
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" }}
- Juerg_Wiesmann
Nimbostratus
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" }}
- Juerg_Wiesmann
Nimbostratus
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.
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com