User are receiving the following message in application:
This page is used to hold your data while you are being authorized for your request.
You will be forwarded to continue the authorization process. If this does not happen automatically, please click the Continue button below.
The interim white page that is displayed will occur when PostPreservation takes place. With a single domain, PostPreservation takes place only when the SMSESSION is no longer valid however when you have multiple domains, PostPreservation also takes place when the cookie in the primary domain needs to be updated in order to maintain SSO between multiple domains. The ACO parameter "SessionUpdatePeriod" dictates the frequency that the web agent in the second domain redirects to update the SMSESSION cookie in the primary domain.
This has the same default value of SessionGracePeriod. If the request is of a POST method and the web agent needs to go talk to the cookie provider (caused by the secondary cookie is no longer valid or the SessionUpdatePeriod is updated), then the web agent in the secondary domain will need to speak with the web agent in the primary domain. This is done via a HTTP 302 redirect and as such, in order to maintain the data, SiteMinder must invoke PostPreservation and this will result in the white page being displayed to the user. If PostPreservation is disabled, then the data that the user submitted will be lost and the user will need to resubmit the data before the SessionUpdatePeriod is exceeded.
If you are running multiple domains, then you have the following options:
- Disable PostPreservation by setting PreservePostData=no in the ACO. This would force the users to have to resubmit their POST data each time we redirect to the cookie provider (as dictated by the SessionUpdatePeriod / validity of the SMSESSION cookie)
- Increase the SessionUpdatePeriod so that we don't redirect to the cookie provider as often. However you will run into this situation if the SessionUpdatePeriod is exceeded. If you choose this option, make sure that the SessionUpdatePeriod does not exceed any idle/max timeouts otherwise there is the chance that sessions in the primary domain are in fact expired.
- Use a combination of solutions by increasing the SessionUpdatePeriod and to avoid the white page that is presented when PostPreservation is in effect, the web agent was enhanced to allow a custom page to be displayed instead of the white page that is displayed by default.
- In v5QMR8 and v6QMR5, a new agent parameter was introduced called "LegacyCookieProvider". When this parameter is enabled, the agent will not go to the cookie provider in case of a POST request even if the cookie needs to be revalidated. (Used when a framework Agent sends a POST request to a traditional Web Agent configured as a cookie provider.)
If the white page is aesthetically not pleasing, this white page can now be replaced with a specified file.
Modify the Session Grace Period
Web pages are typically made up of many resources, all of which are potentially protected by the Web Agent. For each resource associated with a single request, a session cookie is generated. To eliminate the overhead of generating multiple session cookies for a single user request, you can define a grace period between each cookie generated.
The SessionGracePeriod parameter allows a grace period, in seconds, between the regeneration of SMSESSION cookies. The default grace period is 30 seconds.
You can modify the SessionGracePeriod parameter by entering a higher or lower value. If you increase the amount of time, ensure the value is not greater than the session or idle timeout value.
The SMSESSION cookie will not be regenerated if all of the following apply to the request:
- There is no URL SMSESSION cookie.
- The difference between the current time and the last access time of the received SMSESSION cookie is less than or equal to the SessionGracePeriod.
- At least two grace periods must have elapsed between the current time and when the received cookie would have been idle.
Modify the Session Update Period
The SessionUpdatePeriod parameter dictates how often the Web Agent should redirect a request to the Cookie Provider to set a new cookie. The default period is 60 seconds. Refreshing the master cookie decreases the possibility that it will expire due to an idle timeout of the SiteMinder session. This setting is only valid when the CookieProvider parameter has been defined.
Ignore the Cookie Provider for POST Requests (framework agents only).
When a framework Agent sends a POST request to a traditional Web Agent configured as a cookie provider, the redirected request becomes a GET instead of a POST and fails. To control whether or not a POST request is sent to a cookie provider, use the LegacyCookieProvider parameter. This parameter is only valid for framework Agents. If this parameter is set to NO, which is the default, the framework Agent sends the POST request to the cookie provider. If this parameter is set to YES, the framework Agent does not send the POST request to the cookie provider.
Note: If you are using central configuration, you will have to add this parameter to the Agent Configuration Object.