Cookies and Browser Storage

ACE Widgets may need to persist data on the client to function correctly. This data is categorized, allowing end users to choose which types of entries they want to allow. The data is grouped into three categories:

• Necessary: These data entries are essential for the widgets to operate securely and correctly, ensuring that basic functions are possible and that the service requested is provided.
• Functional: These data entries enable additional functionalities that enhance the overall user experience, such as storing login details and user preferences.
• Analytics: These data entries provide insights into how the app is used, facilitating improvements to the user experience.

Updating Storage Policies

To control which categories the widget is allowed to store data in, you can use the Runtime API to set these permissions programmatically.

Example: Allow Only Necessary Storage

The following example restricts storage to only necessary entries:

ace.configure((config) => {
  // This will only allow storing necessary entries.
  config.storagePolicy(['necessary']);
});

Example: Allow All Types of Storage

The following example allows all types of storage, including necessary, functional, and analytics:

ace.configure((config) => {
  // This will allow storing necessary, functional, and analytics entries.
  config.storagePolicy(['necessary', 'functional', 'analytics']);
});

Blocking Specific Storage Entries

If you need to prevent certain entries from being stored by the widget, you can use the disallowStorageKey() method.

Example: Block a Specific Storage Key

The following example blocks the widget from storing any entries under the 'open' key:

ace.configure((config) => {
  // This will prevent storing entries with the key 'open'.
  config.disallowStorageKey('open');
});

Mapping Custom Policies

If your site already has a cookie policy in place, you can map these policies to the widget's storage categories. This ensures consistency across your site's data storage policies.

Example: Map Site Policies to Widget Storage Policies

The following example demonstrates how to map existing site policies to the widget's storage categories:

ace.configure((config) => {
  const widgetPolicies = [];
  const alreadyConfiguredPolicies = []; // Replace with your site's existing policies

  if (alreadyConfiguredPolicies.includes('some-other-policy')) {
    widgetPolicies.push('necessary');
  }

  if (alreadyConfiguredPolicies.includes('some-policy-which-should-be-mapped-to-analytics')) {
    widgetPolicies.push('analytics');
  }

  // Apply the mapped policies to the widget
  config.storagePolicy(widgetPolicies);
});

This example ensures that the widget's storage policies align with your site's existing data management policies, providing a seamless and compliant experience for users.

Storage Entry Naming Convention

When ACE Widgets store data on the client, each entry follows a specific naming convention to ensure uniqueness and easy identification. The format used for storage entries is:

ace_${shortId}-${key}

Breakdown of the Naming Convention:

• ace_: This prefix identifies the entry as being related to ACE Widgets.
• ${shortId}: A 7-character identifier derived from the widget's unique ID. This ensures that entries associated with different widgets remain distinct.
• ${key}: The specific key representing the type of data being stored (e.g., open, preferences).

Example

For a widget with a shortId of abc1234 and a storage key open, the corresponding storage entry would be:

ace_abc1234-open

This naming convention allows for organized and collision-free storage of widget-related data within the client's browser, even when multiple widgets are used on the same site.