Static Resource Synchronization

Starting in release 9.0.005.15, Genesys Co-browse can be used with websites that are fully authenticated, without the need for deploying and configuring intermediate proxy equipment, or without the need for domain whitelisting (that is, no need to configure the allowedExternalDomains option).

Why does Co-browse need to sync static resources?

Synchronizing resources that are placed behind authentication, provides Co-browse with an opportunity to render a web page the same way for both the customer and the agent, enabling them to have a fully synced co-browsing experience. In earlier releases, static resources behind authentication could not be synced and resulted in different page views or 401 unauthorized error messages during a co-browsing session.

The synced resources can be images, CSS stylesheets, fonts, and resources from style tags.

Configuring static resource synchronization

In order for Co-browse to reach all resources, cache them, and then provide them directly to the agent-side, use the following options:

• The enableStaticResourceService option of the JavaScript Configuration API manages the static resource synchronization. This option is set to true by default, so resources will be cached. Setting this option to false turns off the feature.

• The [redis] cache.ttl configuration option specifies the retention policy for 2-level cache and is used to determine how much time the resource will be stored. This option is set to 1h by default. Note that the retention policy for 1-level cache (local cache) is 30 minutes, and is not configurable.

Important

• The resource is cached even if its location is not included in the allowedExternalDomains configuration option.
• If the resource is not successfully cached, there is an attempt to load it directly from its original location on the agent side or to proxy it through Co-browse server. This occurs even if the location is not included in the allowedExternalDomains configuration option.

Resource synchronization mechanism

When you turn on the static resource feature, the main way for Co-browse to sync any resource will be to cache it on the Co-browse server. However, there is a chance that this mechanism could fail for a resource. In these cases, Co-browse will try other ways to sync the resource to the agent-side. By default, for the resource where caching failed, Co-browse attempts to sync the resource to the agent-side via server-side sync and/or to get the resource directly from its location. This backup mechanism depends on the type of resource, its location, and Co-browse configuration.

You can disable the server-side CSS sync mechanism using the css option in the JavaScript Configuration API.

<script>
var _genesys = {
    cobrowse: {
        css: {
          server: false
        }
    }
};
</script>

In this case, if resource caching is unsuccessful, Co-browse only attempts to load it directly from its location.

If you turn on the static resource feature and do not turn off the server-side sync (which is on by default):

<script>
var _genesys = {
    cobrowse: {
        enableStaticResourceService: true,
        css: {
          server: true
        }
    }
};
</script>

OR

<script>
var _genesys = {
    cobrowse: {
        enableStaticResourceService: true,
    }
};
</script>

You will still need to configure domain whitelisting to set the allowedExternalDomains option.

If you do not want to configure domain whitelisting, and to use server-side sync as a backup for the static resource feature, you can disable the server-side sync:

<script>
var _genesys = {
    cobrowse: {
        enableStaticResourceService: true,
        css: {
          server: false
        }
    }
};
</script>

In this case, the only backup mechanism for resources that are not cached will be to get them directly from their location.

Limitations

For information about known issues, see the Co-browser Server 9.0.x Release Note.

Co-browse handles the agent side CSS resources only in UTF-8. Use of multi-byte encoding like shift_jis on the webpage may encounter parsing issues. As per the W3C recommendation, use UTF-8 encoding.