Forum Discussion
Persistence after 302 redirect - header replacement Irule best method or others better?
Gotcha. From an architectural perspective, the best way is to ensure that the SSO layer uses shared memory to store authentication tokens, or is able to source the tokens from a shared backend. However if you need another solution, this is the first thing I think of....
I'm going to assume for the purposes of discussion that your sso domain is called sso.knapp.com and you app is called app.knapp.com (this won't work unless they share a domain). What we are going to do is to change the domain of the sso persistence cookie to be at the knapp.com level rather than the sso.knapp.com level;
when HTTP_RESPONSE {
if {[HTTP::cookie exists "sso_knapp"]} {
This assumes the cookie attached to the sso virtual is called sso_knapp
HTTP::header replace Set-Cookie "sso_knapp=[HTTP::cookie "sso_knapp"]; Domain=knapp.com"
}
}
This means that the sso_knapp cookie will be passed by the browser to requests to the app.knapp.com domain. Then, you just need to get your developer (on app.knapp.com) to include the cookie called sso_knapp from the browser request, in the request to sso.knapp.com and your request will be sent to the same server as the original signon.
I hope that is helpful.
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