On This Page:

Browser Session Duplication

ServiceManager is supported to run within a number of different Browsers. This section covers some of the previously seen issues that relate to the browsers in use. If such a problem is reported to you then please review this section for the Reason/Resolution before reporting any issue to the ServicePower Support team.

The Problem

Whilst ServiceManager appears to be operating correctly there are periodic instances where by ServiceManager users gain access to an incorrect/unexpected selection of operatives. The two most common examples of this problem are: inconsistent changes to a user’s Default Set of operatives; and the wrong set of operatives displayed within the Booking pages.

Default Set Inconsistencies	In most customer environments changes to the default operative set work correctly – the user changes their operative selection and ServiceManager pages are updated to reflect this new set. However there can be circumstances where the user appears to have changed the default set and yet ServiceManager behaves as though the default set contains a different collection of operatives.
Booking Pages	When booking either appointments or SLAs the user is presented with a pick list of available operatives. The population of this list is dependent upon the user’s permissions (i.e. which operatives that user is authorised to interact with). There are certain circumstances where this pick list is incorrect – the list contains operatives that the user is not authorised to interact with.

The Reason

Web applications use session identifiers to track the interaction between each the browser and itself. By default Tomcat uses cookies component of the HTTP header to transport this information within each request/response.

There are certain infrastructure environments where cookie-based session management is not appropriate and the above problem occurs. Typically these manifest themselves because different browser instances have been configured to share cookies.

If cookies are shared between browser instances then each (cookie sharing) browser will use the same browser-cached cookie for its session identifier. ServiceManager assumes that all requests containing the same session identifier was instigated by the same browser. If cookies are shared then the session based data stored within ServiceManager to become overwritten.

The Resolution

There are two possible modes of resolution: disable browser-based cookie sharing and URL rewriting:

Disable Browser-based Cookie Sharing	Browser-based cookie sharing is a client/customer infrastructure issue. Some resource environments (such as Cytrix) allow sharing of cookies across browser instances, or sharing of the actual browser resource. These features should be disabled (consult the appropriate manual) in order for each instance of the browser to have its own unique cookie.
URL Rewriting	It is possible to configure the application server to use URL rewriting, rather than cookies, as the transport mechanism for the session identifier. URL rewriting includes the session identifier as a parameter within the URL itself. Because of this each browser will have its own unique identifier.

To disable cookies Tomcat’s context.xml configuration file (located within the SERVICEManager\tomcat\conf directory) must be modified to include the name of the web application (typically ServiceManager) and the cookies parameter (set to false):

<Context path='/SERVICEManager' cookies='false'>
...
</Context>

Browser not supported