We had accomplished this when we used an external login page with some iRules that would add the initial URI to the query string as a parameter, and then if the user went to the page with a GET (instead of a POST, as the APM redirect would do), it would redirect to that uri (e.g. /service1), which our other iRule would grab that as the start uri.
In my attempt to rework the way we're using APM, I'm working on something similar for the built-in login page. In an iRule, you can use the
HTTP_RESPONSE_RELEASE
event to check for the redirect to /my.policy and update the uri from there so they could bookmark that page. So in the
ACCESS_SESSION_STARTED
event, you could set a custom session variable for the start uri (i.e. session.custom.starturi),and then update the uri to include that on the login page.
when HTTP_RESPONSE_RELEASE {
switch [HTTP::status] {
301 -
302 {
switch -glob [HTTP::header value Location] {
"/my.policy" {
switch [ACCESS::session data get session.custom.starturi] {
"" -
"/" {
}
default {
HTTP::header replace Location "[HTTP::header value Location]?r=[URI::encode [ACCESS::session data get session.custom.starturi]]"
}
}
}
}
}
}
}
After that, you'll need to make sure the
ACCESS_SESSION_STARTED
event handler also handle uris with my.policy in them..
when ACCESS_SESSION_STARTED {
switch -glob [HTTP::uri] {
"/?r=*" {
If we have an empty path and an "r" parameter, we'll use that as the starturi
The "r" param SHOULD be uri encoded
set starturi [URI::decode [URI::query [HTTP::uri] "r"]]
if { $starturi starts_with "/my.policy?r=" } {
set starturi [URI::decode [string range $starturi 13 end]]
}
}
default {
set starturi [HTTP::uri]
}
}
ACCESS::session data set session.custom.starturi $starturi
}
Then your iRule for handling starturis can deal with the redirect after the user is authenticated.
Hope this helps...
Cirrus
