Prérequis pour un domaine personnalisé qui utilise un service ou un CDN tiers

Mise à jour de la configuration DNS de votre domaine

Lorsque vous ajoutez un domaine personnalisé, Salesforce vérifie le DNS pour s'assurer que vous êtes propriétaire du domaine. Avant de configurer votre domaine personnalisé qui utilise un service ou un CDN tiers, mettez à jour le DNS pour inclure l'enregistrement CNAME (nom canonique) ou Texte (TXT) requis pour votre domaine.

• Si votre domaine a un enregistrement A, AAAA ou CNAME existant, vous ne pouvez pas ajouter un enregistrement CNAME. Utilisez à la place un enregistrement TXT dans le DNS pour configurer un domaine non-HTTPS temporaire. Consultez Utilisation d'un domaine non-HTTPS temporaire pour servir votre domaine personnalisé.
• Sinon, ajoutez un enregistrement CNAME dans le DNS qui pointe vers le CNAME *.live.siteforce.com de votre organisation. Consultez Pointage de votre domaine personnalisé avec votre organisation Salesforce.

Après avoir configuré votre domaine qui utilise un service ou un CDN tiers, vous pouvez supprimer l'enregistrement TXT ou CNAME. La suppression des enregistrements DNS inutiles peut améliorer les performances. Vous pouvez également garder l'enregistrement CNAME dans le DNS pour faciliter le basculement vers une autre option de configuration du domaine. Si vous choisissez de garder l'enregistrement, contactez votre fournisseur tiers pour vous assurer que ses services sont pris en charge avec cette configuration.

Vérification que les protocoles HTTP requis sont autorisés

Certains hôtes tiers, CDN et pare-feux d'application Web (WAF) limitent les protocoles HTTP. Lorsque le fournisseur tiers qui sert votre domaine personnalisé n'autorise pas les protocoles HTTP DELETE et PATCH, les utilisateurs ne peuvent pas exécuter dans Salesforce des actions qui s'appuient sur ces protocoles.

Par exemple, un CDN tiers sert un domaine personnalisé et un domaine personnalisé sert une page de site Experience Cloud avec un tableau de bord CRM Analytics incorporé. Si ce CDN tiers n'autorise pas les protocoles HTTP PATCH et DELETE, les utilisateurs peuvent créer une vue dans ce tableau de bord, mais ils ne peuvent pas modifier ni supprimer cette vue.

Pour éviter ces problèmes, vérifiez que votre service ou CDN tiers autorise les protocoles HTTP POST, PUT, PATCH et DELETE. Si le fournisseur restreint ces protocoles par défaut, demandez-lui de les autoriser pour votre domaine avant d'activer votre domaine personnalisé.

Mise en cache

Assurez-vous que lorsque votre service proxy ou CDN traite une requête entrante sans réponse mise en cache, le service transmet la requête au nom d'hôte cible de votre domaine personnalisé en utilisant HTTPS.

De plus, lors de la mise en cache des réponses, votre CDN doit honorer l'en-tête de réponse Cache-Control Salesforce. Vérifiez en particulier que votre CDN respecte ces règles lorsqu'il fonctionne en tant que serveur reverse-proxy.

• Votre CDN met en cache les réponses uniquement lorsque public existe dans l'en-tête de réponse de Salesforce Cache-Control.
• Si private, no-store, ou no-cache existe dans l'en-tête de réponse de SalesforceCache-Control, le CDN ne met pas cette réponse en cache.
• Pour déterminer la durée du cache, le CDN utilise s-maxage, s'il est présent dans l'en-tête de réponse Cache-Control Salesforce. En l'absence de s-maxage, le CDN utilise max-age. Le CDN n'augmente jamais la durée du cache, qu'elle soit dérivée de s-maxage ou de max-age.

Configuration des requêtes : en-tête HTTP Host

Pour servir votre domaine personnalisé avec un service ou un CDN tiers, configurez votre proxy ou service CDN afin que les requêtes envoyées à Salesforce contiennent l'en-tête HTTP Host de la requête d'origine. En d'autres termes, vérifiez que le nom de votre domaine personnalisé (domaine affiché dans la requête du navigateur Web d'origine pour les utilisateurs) est la valeur de l'en-tête HTTP Host dans les requêtes envoyées à Salesforce.

Par exemple, un CDN non-Salesforce sert votre domaine personnalisé www.exemple.com. Lorsqu'un navigateur Web demande https://www.exemple.com/hello/world, votre CDN envoie la requête à Salesforce à l'adresse https://MonNomDeDomaine.my.salesforce.com/hello/world, en définissant l'en-tête Host sur www.exemple.com. Salesforce traite ensuite la requête à l'adresse NomMonDomaine.my.salesforce.com en tant que requête pour www.exemple.com avec le chemin /hello/world. Si l'en-tête Host n'est pas défini sur votre domaine personnalisé, Salesforce ne traite pas correctement la requête.

Chemins d'URL dans les requêtes

Assurez-vous que votre service ou CDN tiers traite les requêtes sans décoder le chemin des URL demandées. Par exemple, si le chemin d'accès comprend %2F, Salesforce exige que l'URL comprenne %2F, et non la valeur ASCII décodée, /.

Pointage de votre domaine personnalisé vers votre organisation avec votre nom d'hôte cible

Pour pointer votre domaine personnalisé qui utilise un service ou CDN tiers vers votre organisation, le tiers utilise un nom d'hôte cible. Un nom d'hôte cible est le nom d'hôte vers lequel votre proxy ou CDN transmet les requêtes à votre domaine personnalisé. En d'autres termes, le nom d'hôte cible désigne la méthode de livraison utilisée par votre service ou CDN tiers pour livrer des contenus depuis vos sites dans Salesforce.

Pour les domaines personnalisés qui utilisent un service ou un CDN tiers, l'URL de connexion Mon domaine de votre organisation est le nom d'hôte cible du domaine. Avec votre fournisseur tiers, transmettez vos requêtes proxy ou CDN à ce nom d'hôte.

Pour obtenir le nom d'hôte cible à fournir à votre service ou CDN tiers, dans Configuration, recherchez et sélectionnez Domaines, puis cliquez sur Ajouter un domaine.

Lorsque vous sélectionnez Utiliser un service ou CDN tiers pour servir le domaine, votre nom d'hôte cible est inclus dans le guide de cette option de configuration du domaine.

Restrictions proxy inverse

Un proxy inverse est un type de serveur proxy utilisé pour orienter les requêtes clients vers le serveur qui fournit la ressource demandée. Comme les proxies inverses peuvent augmenter l'évolutivité, les performances, la résilience et la sécurité, les grands sites Web et CDN les utilisent souvent dans le cadre de leurs techniques d'équilibrage de charge.

Pour vous assurer que le trafic est acheminé vers l'URL du site correct, il est préférable que le serveur proxy inverse de votre service ou CDN tiers transfère le chemin relatif à la racine complet de votre site. Par exemple, lors de la livraison de ressources depuis, le serveur proxy inverse du service ou du CDN transmet /store/sales, pas le chemin relatif /sales. Sinon, certaines pages et fonctionnalités risquent de charger des ressources depuis des chemins extérieurs au préfixe d'un site.

Si votre service ou CDN tiers refuse de transmettre le chemin relatif à la racine complet pour toutes les requêtes, nous recommandons vivement de tester votre domaine personnalisé afin de vérifier l'absence de problèmes. Pendant le test, identifiez les emplacements auxquels les ressources ne sont pas correctement chargées. Ensuite, avec votre service ou CDN tiers, mettez à jour le serveur proxy inverse afin de gérer correctement ces requêtes.

Configuration de votre CDN pour transmettre l'adresse IP d'origine

Si vous utilisez un CDN externe et le ciblage d'audience basé sur la localisation dans Experience Cloud, définissez l'en-tête HTTP True-Client-IP dans votre CDN externe. Sans cet en-tête, le ciblage d'audience peut renvoyer des résultats inattendus.

Si vous utilisez un CDN externe et des restrictions d'adresses IP pour le ciblage d'audience basé sur l'emplacement dans Experience Cloud, définissez l'en-tête True-Client-IP dans votre CDN externe. Ce paramètre facilite la transmission de l'adresse IP du client d'origine à Salesforce. Sans cet en-tête, les appels à votre site et le ciblage d'audience peuvent renvoyer des résultats inattendus. Pour plus d'informations sur le suivi et les restrictions d'adresses IP avec un domaine personnalisé, consultez Considérations relatives aux domaines personnalisés qui utilisent un service ou un CDN tiers.

Pour plus d'informations sur la définition de l'en-tête True-Client-IP, notamment les paramètres supplémentaires recommandés pour vous protéger contre l'usurpation d'adresses, consultez la documentation du fournisseur de votre CDN.