Forum Discussion
JP88730K_296639
Nimbostratus
NimbostratusAPM Session Visibility across VIPs
What is the best way to establish session visibility across multiple APM sessions without a SSO configuration or a persistent cookie? My site hosts projects which have multiple virtual servers. We us...
The browser must simply include the cookie in the request to be associated with the session. RFC 6265 defines exactly how this works, if you aren't familiar with it. The wikipedia article on HTTP cookies is also very good.
Customers usually choose one of the following options to share the cookie across multiple vips/hostnames:
-
Set the cookie domain to be wide like ".company.com" so that the cookie will be transmitted to *.company.com.
-
Use APM's multi-domain mode so that when APM gets a request without a cookie, it will "check with" the domain set as the primary-authentication URI to see if it's been set. This happens by using some 302 redirects between the hostanmes/vips.
For either of these options, make sure the session scope is set appropriately.
-
The browser must simply include the cookie in the request to be associated with the session. RFC 6265 defines exactly how this works, if you aren't familiar with it. The wikipedia article on HTTP cookies is also very good.
Customers usually choose one of the following options to share the cookie across multiple vips/hostnames:
-
Set the cookie domain to be wide like ".company.com" so that the cookie will be transmitted to *.company.com.
-
Use APM's multi-domain mode so that when APM gets a request without a cookie, it will "check with" the domain set as the primary-authentication URI to see if it's been set. This happens by using some 302 redirects between the hostanmes/vips.
For either of these options, make sure the session scope is set appropriately.
JP88730K_296639So if I go with the first option and set a domain wide cookie, can it's existence be queried in APM?
expr {HTTP::cookie exists *.company.com} to Allow
fallback to EULA prompt
APM has session state management built-in, you don't need to do anything like that. Also that's not really the right way to call HTTP::cookie.
If the browser transmits the APM session cookie (MRHSession) and the session is in "allow" state, then the request will be allowed without re-executing the access policy.