Le domaine d'un fournisseur

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 adresseLien vers cette section#

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 plateformeLien vers cette section#

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 SaaSLien vers cette section#

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 pour cette zone en premier.

1. Origine de secoursLien vers cette section#

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 :

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.

2. Route WorkerLien vers cette section#

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.

{ "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 :

{ "pattern": "tradecatalog.app", "custom_domain": true }

{ "pattern": "*.tradecatalog.app/*", "zone_name": "tradecatalog.app" }

Et laissez la route du Worker de test telle quelle :

{ "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ésLien vers cette section#

L’application appelle l’API des noms d’hôte personnalisés 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 ajouteLien vers cette section#

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.