Didomi - Developers documentation
  • Introduction
  • SDKs
    • Introduction
    • Web SDK
      • Getting started
      • Tags and vendors management
        • Tags management
          • Events & Variables
            • Deprecated
            • Custom events
          • Tag managers
            • Adobe Launch/DTM
            • Eulerian
            • Google Tag Manager
              • Configure the Didomi / GTM integration
              • Didomi's GTM template
            • Tealium
            • Other tag managers
        • Custom Didomi <script> tags
        • Third-party integrations
          • Google Ad Manager / AdSense
            • GDPR via Non-Personalized Ads
              • Share consent and load/refresh ads
              • Share consent without loading or refreshing ads
            • US states laws
          • Google Consent Mode V2
          • Kameleoon
          • Piano Analytics (AT Internet)
          • Prebid
            • GDPR via IAB TCF
            • US states laws
          • Salesforce DMP (Krux)
        • IAB frameworks
        • Programmatic API
      • Configuration
        • Bots (SEO & Performance tools)
        • Configuration by URL
        • Cookies and storage
        • Custom domains for events
        • Notice
          • Behavior
          • Interactions
          • Look and feel
        • Preferences
        • Theme
      • AB tests
      • Custom domain
        • Domain delegation
        • Reverse proxy
      • Share consents between domains
      • Share consents across devices
      • Pass user choices in query string
      • Serve Didomi assets from your domain
      • Reference
        • API
          • Deprecated
        • Events
      • Performance
      • Versions
    • Mobile and TV SDKs
      • Android and Android TV
        • Setup
        • Logging
        • Reference
          • API
            • Deprecated
          • Events
        • Versions
      • iOS and tvOS
        • Setup
        • Logging
        • App Tracking Transparency (iOS 14.5+)
        • Reference
          • API
            • Deprecated
          • Events
        • Versions
      • Unity
        • Setup
        • Reference
        • Versions
        • Troubleshooting
      • React Native
        • Setup
        • Reference
          • Deprecated
        • Versions
      • Flutter
        • Setup
        • Reference
        • Versions
      • Consent notice
        • Getting started
        • Customize the notice
        • Customize the preferences popup
        • Customize the theme & UI
        • Load notice by ID
      • Third-party SDKs
      • Share consents across devices
      • Share consent with WebViews
      • Google Consent Mode v2
      • FAQ
    • AMP SDK
      • Blocking Behaviors
        • Load immediately on page load
        • Load only after consent (positive or negative)
        • Load only after positive consent
      • Consent status for vendors
    • Help & Support
  • API
    • Introduction
      • Authentication
      • Errors
      • Pagination
      • Filters
      • Caching
      • Rate limiting
      • Quotas
      • Translations
    • Data Manager
      • Regulations
      • Configuration Tree
      • Purposes
        • Purposes & Vendors Numerical IDs
      • Preferences Library
      • User Rights
    • Widgets
      • Consent notices
        • Notices
        • Configurations
        • Multi-Regulation Configurations
          • Migration of Existing Notices and API Updates
        • Deployments
        • Tutorials
          • Create and publish a consent notice
          • Create and publish a multi-regulation consent notice
      • Privacy widgets
        • Create a widget
        • Retrieve widgets
        • Edit a widget
          • Content & Design
            • Themes & Shapes
            • Components
              • auth
              • dsar_form
              • footer
              • header
              • preference
              • preference_value
              • save
              • section
              • sections
            • Options
          • Purposes & preferences
          • Settings
        • Deploy a Widget
          • Use your own subdomain
          • Use your own domain
          • Implement an embeddable widget on your website
        • Authentication
          • Manage authentication providers
          • Authenticate your end-user
        • Archive a widget
        • Headless widgets
          • Public Methods
          • Custom elements
          • Custom events
          • Event listeners
        • Tutorial
          • Launch a Preference Center from a mobile app
    • Compliance Reports
      • Properties
      • Reports
      • CSV format reference
      • Websites
    • Consents and Preferences
      • Events
        • Generate IAB TCF consent string
      • Links
      • Proofs
      • Tokens
      • Secrets
      • Users
      • Tutorial
        • Collect and operate data
    • Privacy Requests
      • Requests
      • Notes
      • Links
      • Emails
  • Integrations
    • Introduction
      • Quotas
    • Generic integrations
      • Batch export
        • Destinations
          • AWS S3 Bucket (owned by Didomi)
          • GCP Storage Bucket
        • Exported data
          • Notices consents
        • Logs
      • Webhooks
      • Batch import
      • Analytics export
        • Destinations
          • AWS S3 Bucket (owned by Didomi)
          • GCP Storage Bucket
    • Third-party apps
      • CMP integrations
        • Didomi-mParticle integration for your CMP
        • Deploy Didomi’s SDK for your Adobe Commerce website
      • Preference Management Platform integrations
        • Actito
        • Adobe Campaign Classic
        • Adobe Experience Cloud
        • Adobe Marketo Engage
        • Adobe Source Connector
        • Braze
        • Dotdigital
        • Hubspot
        • Mailchimp
        • Microsoft Dynamics 365
        • Salesforce Marketing Cloud
        • Salesforce Sales & Service Cloud
        • Selligent
        • Brevo (ex Sendinblue)
    • Tutorials
      • Configure a HTTP webhook
      • Configure a batch export
      • Configure an analytics export
    • Emailing
      • Configurations
        • Actito Email
        • Actito SMS
        • Adobe Campaign Classic
        • Adobe Campaign Standard
      • Emails
        • Templates
        • Manage your templates
Powered by GitBook
On this page
  • Introduction
  • Configuration
  • Setting user organization ID
  • Which organization user ID to share with Didomi?
  • Authentication with a hash digest
  • Behavior
  • Frequency
  • Sync timeout
  • Delaying notice showing
  • Multi-account
  • Troubleshooting
  1. SDKs
  2. Mobile and TV SDKs

Share consents across devices

PreviousThird-party SDKsNextShare consent with WebViews

Last updated 2 months ago

Introduction

The Didomi CMP supports syncing to allow consent sharing across devices and environments. Consent can be shared between all environments that have syncing enabled in the same organization: multiple websites, multiple apps (same or multiple devices), multiple websites and apps together, etc.

When syncing is enabled and an organization user ID is available, the Didomi CMP will load the previously stored user choices from the Consents API and will apply them locally.

Syncing is currently a premium feature. You can schedule a meeting with our Support team to enable the feature for your account.

Configuration

Setting user organization ID

For the sync process to work properly, an User Organization Id property needs to be set before the Didomi initialization:

Didomi.getInstance().setUser("organization-user-id");
Didomi.getInstance().setUser("organization-user-id");
Didomi.shared.setUser(id: "organization-user-id")
Didomi *didomi = [Didomi shared];
[didomi setUserWithId:@"organization-user-id"];
await DidomiSdk.setUser("organization-user-id");
await Didomi.setUser("organization-user-id");
Didomi.setUser("organization-user-id");

This value represents the unique identifier with which the organization identifies the user for which it wants to sync the consents. This can be an email address, a user ID, etc. We recommend hashing the value to not communicate plain user IDs to Didomi.

Note: This value is not stored in user data and should be set again at each session.

Which organization user ID to share with Didomi?

When the user is identified by the application through a login process or any other authentication method, a unique user ID should be shared with the Didomi SDK through the Didomi.setUser() method. The unique user ID can be any string but we recommend sending a hashed version of your internal user ID to not expose any sensitive data on the page or to Didomi. Avoid sharing plain email addresses, user names, etc. with Didomi.

The same unique user ID will need to be shared in other environments like mobile apps. If you are sending a hashed ID, make sure that you will be able to send exactly the same ID in from environments.

The user ID shared on the website will be used as the organization user ID in our . If you are accessing the user status or event from the API, you will need to specify the same user ID as what is shared on the website, including any form of anonymization or hashing method in place. The organization user ID must be consistent across your organization and all the other Didomi products you are using (APIs, Privacy Center, etc.).

Authentication with a hash digest

Using a hash digest does not guarantee the confidentiality of the user ID passed to Didomi as it is exposed in clear text on the page.

As the user ID is provided in a public environment (on a webpage), we need to authenticate it to guarantee that users cannot freely read and write consents for any user ID.

To authenticate the user ID and prove that it was authorized by the application, you will need to compute a hash digest of the user ID concatenated with a secret. This digest must be computed directly by your application in an authenticated context and not on the client-side. When it receives a request, Didomi will re-compute the digest with the secret and make sure that it matches the digest that you provided.

The hash digest should be provided in the digest parameter. You will also need to provide the ID of the secret and the hashing algorithm used for generating the hash digest.

Example:

Didomi.getInstance().setUser(new UserAuthWithHashParams(
            "organization-user-id",
            "algorithm",
            "secret_id",
            "digest"
));
Didomi.getInstance().setUser(UserAuthWithHashParams(
            id = "organization-user-id",
            algorithm = "algorithm",
            secretId = "secret_id",
            digest = "digest"
));
Didomi.shared.setUser(userAuthParams: UserAuthWithHashParams(
            id: "organization-user-id",
            algorithm: "algorithm",
            secretID: "secret_id",
            digest: "digest"
))
[didomi setUserWithUserAuthParams: [[UserAuthWithHashParams alloc]
                                    initWithId:@"organization-user-id"
                                    algorithm: @"algorithm"
                                    secretID: @"secret-id"
                                    digest: @"digest"
                                    salt: NULL]];
await setUserWithAuthParams(new UserAuthWithHashParams(
        "organization-user-id",
        "algorithm",
        "secret_id",
        "digest"
));
await Didomi.setUserWithHashAuth(
    "organization-user-id",
    "algorithm",
    "secret_id",
    "digest"
);
Didomi.setUserWithHashParams(
    "organization-user-id",
    "algorithm",
    "secret_id",
    "digest"
);

Secrets

Hashing methods

Didomi supports the following methods for computing a digest:

Algorithm
ID
Description

Hash MD5

hash-md5

Hexadecimal digest computed with the MD5 algorithm

Hash SHA1

hash-sha1

Hexadecimal digest computed with the SHA1 algorithm

Hash SHA256

hash-sha256

Hexadecimal digest computed with the SHA256 algorithm

HMAC SHA1

hmac-sha1

Hexadecimal representation of a HMAC computed with the SHA1 algorithm

HMAC SHA256

hmac-sha256

Hexadecimal representation of a HMAC computed with the SHA256 algorithm

For all methods, the content to compute the digest on and the secret are the same. The method ID must be provided in the algorithm property.

Salting

For increased security, you can use a salt when computing the hash digest. You will need to provide the salt parameter in the configuration so that Didomi can use it when verifying the user ID.

Example:

Didomi.getInstance().setUser(new UserAuthWithHashParams(
            "organization-user-id",
            "algorithm",
            "secret_id",
            "digest",
            "salt"
));
Didomi.getInstance().setUser(UserAuthWithHashParams(
            id = "organization-user-id",
            algorithm = "algorithm",
            secretId = "secret_id",
            digest = "digest",
            salt = "salt"
));
Didomi.shared.setUser(userAuthParams: UserAuthWithHashParams(
            id: "organization-user-id",
            algorithm: "algorithm",
            secretID: "secret_id",
            digest: "digest",
            salt: "salt"
))
[didomi setUserWithUserAuthParams: [[UserAuthWithHashParams alloc]
                                    initWithId:@"organization-user-id"
                                    algorithm: @"algorithm"
                                    secretID: @"secret-id"
                                    digest: @"digest"
                                    salt: @"salt"]];
await setUserWithAuthParams(new UserAuthWithHashParams(
        "organization-user-id",
        "algorithm",
        "secret_id",
        "digest",
        "salt"
));
await Didomi.setUserWithHashAuth(
    "organization-user-id",
    "algorithm",
    "secret_id",
    "digest",
    "salt"
);
Didomi.setUserWithHashParams("organization-user-id",
            "algorithm",
            "secret_id",
            "digest",
            "salt");

Information expiration

The authentication methods guarantee the integrity of the information (i.e., the information originates from the client and cannot be modified by a third-party) but do not guarantee that that information cannot be reused.

To prevent reusing an encrypted user identifier, we support the addition of expiration information. You can mark the information as having an expiration date so that it cannot be used after a certain date using the expiration parameter. This should be a valid unix timestamp value.

Example:

Didomi.getInstance().setUser(new UserAuthWithHashParams(
            "organization-user-id",
            "algorithm",
            "secret_id",
            "digest",
            "salt", // or null
            10000L
));
Didomi.getInstance().setUser(UserAuthWithHashParams(
            id = "organization-user-id",
            algorithm = "algorithm",
            secretId = "secret_id",
            digest = "digest",
            salt = "salt", // or null
            expiration = 10000L
))
Didomi.shared.setUser(userAuthParams: UserAuthWithHashParams(
            id: "organization-user-id",
            algorithm: "algorithm",
            secretID: "secret_id",
            digest: "digest",
            salt: "salt", // or nil
            expiration: 10000
))
[didomi setUserWithUserAuthParams: [[UserAuthWithHashParams alloc]
                                    initWithId:@"organization-user-id"
                                    algorithm: @"algorithm"
                                    secretID: @"secret-id"
                                    digest: @"digest"
                                    salt: @"salt" // or null
                                    legacyExpiration: 10000.0]];
await setUserWithAuthParams(new UserAuthWithHashParams(
        "organization-user-id",
        "algorithm",
        "secret_id",
        "digest",
        "salt", // or null
        10000
));
Didomi.setUserWithHashAuth(
    "organization-user-id",
    "algorithm",
    "secret_id",
    "digest",
    "salt", // or null
    10000
);
Didomi.setUserWithHashParamsWithExpiration("organization-user-id",
            "algorithm",
            "secret_id",
            "digest",
            "salt", // or null
            10000);

The sync process can be enabled with async.enabled configuration option in the Didomi configuration:

{
    "app": {
        ...
    },
    "sync": {
        "enabled": true
    }
}

Behavior

Frequency

By default, the sync process will run once every day. The value in seconds for the sync process can be specified via the frequency configuration option.

{
    "app": {
        ...
    },
    "sync": {
        "enabled": true,
        "frequency": 86400
    }
}

Sync timeout

The maximum time allowed for the syncing process to be completed can be specified with a sync.timeout configuration option in the Didomi configuration:

{
    "app": {
        ...
    },
    "sync": {
        "enabled": true,
        "timeout": 2000
    }
}

The sync.timeout configuration option accepts an integer which represents the maximum time allowed (in milliseconds) for the syncing process to be completed.

If the syncing process takes more time to be completed than it is specified in sync.timeout configuration option, the initialization continues as if there was no data to sync.

Delaying notice showing

It is also possible to call setupUI() only after user was synchronized. Alternatively, current Activity (Android) or ViewController (iOS) can be passed to the setUser method, so if sdk is already initialized, consent will be asked again if user consent is partial after synchronization.

Example:

Didomi.getInstance().setUser(userParams, activity);
Didomi.getInstance().setUser(userParams = userAuthParams, activity = activity);
Didomi.shared.setUser(userAuthParams: userParams, containerController: viewController)

Multi-account

After an organization user ID has been set, it is possible to change it or to "remove" it (forget this user ID). This will be interpreted as changing the currently active organization user, and will trigger a new synchronization.

  • If there was an already synchronized user, and the user changed, the existing consents are reset . If this user already gave consent using another device, these consents will be loaded. Otherwise, the user needs to give consent again.

Troubleshooting

When computing a hash digest, a secret needs to be used. Secrets can be managed through the Didomi API to obtain an actual secret and its associated ID. to manage secrets for your organizations.

On Android and iOS, the parameter is ignored. To avoid showing the notice before user is synchronized, the setUser method can be called before the SDK is initialized. In this case, consent synchronization will be performed as part of the initialization process.

When user should not be synchronized anymore, should be called. When doing this, the Didomi user ID () assigned to this user will be reset, but current consents will be kept. The call will also trigger a event. If you need to reset the consents as well, you can call the method at the same time.

By providing the optional parameter activity (Android) / containerController (iOS) to the method, if the sdk is already initialized, will be automatically called after synchronization is done. So if synchronized user changes and consent is partial for the new user, consent notice will be displayed automatically.

Android Developers, make sure the device is supporting the selected encryption method. For more information, see the .

through the console
Consents API
Read our documentation
Android documentation
delayNotice
consentChanged
clearUser()
UserStatus.userId
reset()
setUser
setupUI