# Le domaine d'un fournisseur > Comment le portail d'un fournisseur Pro est servi à portal.theircompany.com. La source de secours et la route de capture par défaut en production sont activées. Sur Pro, un fournisseur peut définir son propre adresse de portail dans **Paramètres → Identification**, comme `portal.theircompany.com` ou `order.theircompany.com`. Le fournisseur est lu à partir de cet hôte. Une personne ne voit toujours qu'un portail auquel elle appartient. Les employés se connectent à cette même adresse et ouvrent l'espace de travail là-bas. Se déconnecter retourne à la page de connexion de cette adresse. Les acheteurs ouvrent toujours le portail de commerce. Utilisez `portal.` ou `order.` plutôt que le domaine brut. Le domaine brut est là où l'e-mail du fournisseur est configuré, et un CNAME là-bas entrave ces enregistrements de messagerie. L'application refuse un nom brut tel que `theircompany.com`. `theirname.tradecatalog.app` et `tradecatalog.app/p/theirname` continuent à fonctionner. Le courrier est toujours envoyé depuis `orders@tradecatalog.app`. Les pages sur l'adresse du fournisseur envoient `X-Robots-Tag: noindex`. `/mcp`, `/oauth` et `/api/v1` restent sur `tradecatalog.app`. ## Connectez votre adresse Ouvrez **Paramètres → Identification → Votre adresse de portail** sur Pro. 1. Choisissez **Utiliser votre identité visuelle** pour ajouter votre nom, logo et couleurs sur la page de connexion, le portail, les courriels et les documents de commande. Les informations sur le service restent sur la page de connexion. 2. Entrez une adresse telle que `portal.theircompany.com` et choisissez **Enregistrer l'adresse et l'identité visuelle**. Cela enregistre l'adresse et l'identité visuelle ensemble et démarre la vérification. 3. Ajoutez le CNAME indiqué chez votre fournisseur de DNS. Les boutons de copie copient le nom et la cible exacts. Si votre fournisseur ajoute automatiquement votre domaine, entrez uniquement la partie avant votre domaine dans **Nom**. 4. Suivez **Adresse enregistrée**, **Domaine vérifié** et **Connexion sécurisée**. L'activation du nom d'hôte et l'émission du certificat sont des vérifications séparées. Un domaine vérifié ne signifie pas que HTTPS est prêt. 5. Les vérifications se rafraîchissent toutes les 30 secondes pendant jusqu'à dix minutes pendant que cette page est visible. Choisissez **Vérifier à nouveau la connexion** pour réessayer après avoir modifié les paramètres DNS ou si les vérifications automatiques sont en pause. 6. Une fois que **Votre certificat est prêt** s'affiche, vérifiez que votre CNAME pointe vers la cible indiquée et utilisez **Ouvrir votre page de connexion** pour vérifier que votre propre portail s'ouvre en toute sécurité avant de le partager. La disponibilité du fournisseur ne vérifie pas indépendamment l'endroit où votre registraire envoie le trafic. Votre lien de portail existant reste disponible pendant toute la configuration. Les nouvelles adresses utilisent la validation automatique du certificat HTTP. Une vérification de connexion peut réessayer en toute sécurité un certificat en attente sur le même nom d'hôte, sans le supprimer. Les anciennes configurations TXT peuvent passer à la validation HTTP lorsqu'elles y sont éligibles. Les validations DNS déléguées et les certificats wildcard conservent leur méthode existante. Lorsque la validation DNS est nécessaire, toutes les valeurs TXT requises sont affichées, y compris les deux valeurs lorsqu'un même nom partage deux enregistrements. Les enregistrements CNAME de délégation sont une alternative lorsqu'elle est offerte. Gardez les enregistrements de délégation pour les renouvellements ; un CNAME et des enregistrements TXT ne peuvent pas partager le même nom. Pour la validation HTTP automatique, des enregistrements supplémentaires de vérification de certificat sont disponibles sous **Enregistrements supplémentaires de vérification de certificat** plutôt que présentés comme une étape supplémentaire obligatoire. La page affiche l’heure de la dernière vérification et tout problème signalé par le service de certificat. Une tentative échouée conserve votre adresse actuelle et les enregistrements de vérification. Si vous avez besoin d’aide, utilisez **Obtenir de l’aide pour connecter votre adresse**. Vous n’avez pas besoin de gérer les identifiants API de TradeCatalog ou de chercher un bouton de plateforme caché. Laisser l’adresse enregistrée vide et choisir **Supprimer l’adresse et enregistrer la marque** la supprime. Lorsque la plateforme est connectée à Cloudflare, l’ancien nom d’hôte personnalisé est également supprimé là-bas. Cela n’affecte pas vos enregistrements DNS chez votre registraire. ## Pour les opérateurs de plateforme Les sections ci-dessous décrivent l’infrastructure de TradeCatalog, pas les étapes que les fournisseurs doivent accomplir. L’origine de secours et la route de capture de production sont configurées séparément. Ne modifiez pas les identifiants du fournisseur ou les routes de zone en suivant la configuration du fournisseur ci-dessus. ## Cloudflare pour SaaS Faites cela sur la zone `tradecatalog.app`, manuellement, lorsque vous êtes prêt à activer les noms d’hôte personnalisés. [Activez Cloudflare pour SaaS](https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/start/enable/) pour cette zone en premier. ### 1. Origine de secours Le trafic avec un nom d’hôte personnalisé est envoyé à une origine de secours sur votre zone. Pour un Worker, ce registre est sans origine : | Type | Nom | Contenu | Proxy | | ---- | ---------- | ------- | ------- | | AAAA | `fallback` | `100::` | Proxied | Puis définissez l’origine de secours sur `fallback.tradecatalog.app`. Dans le tableau de bord, c’est **SSL/TLS → Hostnames personnalisés → Origine de secours**. Avec l’API : ``` PUT /zones/{zone_id}/custom_hostnames/fallback_origin { "origin": "fallback.tradecatalog.app" } ``` Attendez que cette origine de secours soit **Active**. Voir [Workers comme origine de secours](https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/start/advanced-settings/worker-as-origin/). ### 2. Route Worker Cela est déjà dans les **routes de production** dans `wrangler.jsonc`. Wrangler remplace les routes lors du déploiement, donc en supprimant cette route, vous empêchez le domaine d’un fournisseur d’atteindre ce Worker. Ne l’ajoutez pas à la phase de test. ```json { "pattern": "*/*", "zone_name": "tradecatalog.app" } ``` Cette route envoie tous les hôtes entrant dans la zone vers ce Worker, y compris le domaine d’un client. Les routes plus spécifiques l’emportent, donc laissez les routes déjà présentes : ```json { "pattern": "tradecatalog.app", "custom_domain": true } ``` ```json { "pattern": "*.tradecatalog.app/*", "zone_name": "tradecatalog.app" } ``` Et laissez la route du Worker de test telle quelle : ```json { "pattern": "staging.tradecatalog.app", "custom_domain": true } ``` Ne placez pas `*/*` en phase de test. Ne créez pas de nom d’hôte personnalisé égal à `tradecatalog.app`, `www.tradecatalog.app` ou `fallback.tradecatalog.app`. ### 3. API des noms d’hôte personnalisés L’application appelle l’[API des noms d’hôte personnalisés](https://developers.cloudflare.com/api/resources/custom_hostnames/methods/create/) lorsqu’un fournisseur vérifie une adresse, et uniquement après que ceux-ci soient configurés sur le Worker de production : - `CLOUDFLARE_API_TOKEN` en tant que secret, avec la permission d’édition des noms d’hôte personnalisés et de leurs certificats - `CLOUDFLARE_ZONE_ID` en tant qu’identifiant de la zone `tradecatalog.app` ``` POST /zones/{zone_id}/custom_hostnames { "hostname": "portal.theircompany.com", "ssl": { "method": "http", "type": "dv", "settings": { "min_tls_version": "1.2" } } } ``` Le sondage d’état utilise `GET /zones/{zone_id}/custom_hostnames/{id}`. Une vérification de connexion initiée par le fournisseur peut sécuriser `PATCH` un certificat DV géré par le fournisseur en attente, puis lire à nouveau son état, préservant ses paramètres SSL. Il ne supprime jamais ou recrée un nom d’hôte. Les certificats personnalisés actifs et chargés ne sont pas redémarrés, et la validation déléguée ou les wildcards reste en TXT. La suppression ou le remplacement d’une adresse envoie `DELETE` pour l’ancien identifiant. Les nouvelles adresses utilisent la validation du certificat HTTP : une fois que le CNAME pointe vers l’origine de secours, Cloudflare peut valider automatiquement. Les adresses existantes conservent leur méthode de validation initiale jusqu’à ce qu’elle soit modifiée. Le personnel de la plateforme peut lancer **Vérifier l’adresse** pour toute entreprise depuis le compte client de cette entreprise, et en ouvrant l’espace de travail et en utilisant Paramètres → Marquage. **Réinitialiser la validation du certificat** est réservé au personnel de la plateforme. Il demande à Cloudflare de définir la méthode du certificat sur HTTP. Si Cloudflare ne peut pas changer la méthode sur le nom d’hôte existant, le nom d’hôte est supprimé et recréé avec les mêmes paramètres d’adresse et de certificat, et le nouvel identifiant est enregistré. La confirmation indique que cela modifie le nom d’hôte personnalisé Cloudflare en direct. Pendant que la réinitialisation s’exécute, le bouton de confirmation affiche « Réinitialisation en cours… », affiche une roue de chargement et ne peut pas être cliqué à nouveau. Après cela, la page affiche l’état et les enregistrements DNS à transmettre au fournisseur. La vérification de l’adresse sur le compte client fait la même chose pendant que sa vérification s’exécute. Un propriétaire de fournisseur ne peut pas lancer la réinitialisation. Pour une adresse encore utilisant TXT ou la délégation après une tentative réussie, le fournisseur choisit **Vérifier à nouveau la connexion**, ajoute chaque enregistrement de certificat affiché sous **Ajouter ces enregistrements** chez le fournisseur DNS, puis vérifie à nouveau. Le DNS peut être connecté pendant que le certificat a encore besoin de ces enregistrements. Ne remplacez pas un jeton TXT par l’autre lorsqu’il en est affiché deux. Si la délégation est proposée, utilisez ses enregistrements CNAME au lieu des enregistrements TXT en conflit. L’application ne redirige pas `/.well-known/acme-challenge/` ou `/.well-known/pki-validation/` sur cet hôte. Laissez ces chemins intacts dans toute règle de redirection, afin qu’une vérification de certificat ne soit pas modifiée. ### Ce que le client ajoute Un CNAME pour `portal.theircompany.com` (ou `order.`) pointant vers `fallback.tradecatalog.app`. Recommandez ce nom. Un domaine simple tel que `theircompany.com` ne peut pas être un CNAME normal sans déplacer le courrier électronique, et le proxying de pointe de Cloudflare est une configuration séparée. Ne l'utilisez pas.