# Il dominio del fornitore stesso > Come viene erogato il portale del fornitore Pro su portal.theircompany.com. La rotta di origine di fallback e la rotta di produzione catch-all sono attive. Su Pro, un fornitore può impostare il proprio indirizzo del portale in **Impostazioni → Marchio**, ad esempio `portal.theircompany.com` o `order.theircompany.com`. Il fornitore viene letto da quel host. Una persona vede ancora solo un portale a cui appartiene. Il personale si registra su quel medesimo indirizzo e apre lo spazio di lavoro lì. Effettuando il logout si torna alla pagina di accesso di quell'indirizzo. I compratori continuano a aprire il portale commerciale. Utilizza `portal.` o `order.` invece del dominio base. Il dominio base è dove viene impostata la posta elettronica del fornitore e un CNAME lì combatterebbe quelle registrazioni di posta. L'app rifiuta un nome base come `theircompany.com`. `theirname.tradecatalog.app` e `tradecatalog.app/p/theirname` continuano a funzionare. La posta viene ancora inviata da `orders@tradecatalog.app`. Le pagine del proprio indirizzo del fornitore inviano `X-Robots-Tag: noindex`. `/mcp`, `/oauth` e `/api/v1` rimangono su `tradecatalog.app`. ## Connetti il tuo indirizzo Apri **Impostazioni → Marchio → Il tuo indirizzo del portale** su Pro. 1. Scegli **Usa il tuo marchio** per aggiungere il tuo nome, logo e colori su accesso, portale, e-mail e documenti di ordine. Le informazioni sul servizio restano nella pagina di accesso. 2. Inserisci un indirizzo come `portal.theircompany.com` e scegli **Salva indirizzo e marchio**. Questo salva l'indirizzo e il marchio insieme e inizia il controllo. 3. Aggiungi il CNAME mostrato dal tuo fornitore DNS. I pulsanti di copia copiano il nome e il target esatti. Se il tuo fornitore aggiunge automaticamente il tuo dominio, inserisci solo la parte prima del tuo dominio in **Nome**. 4. Segui **Indirizzo salvato**, **Dominio verificato** e **Connessione sicura**. L'attivazione del nome host e l'emissione del certificato sono controlli separati. Un dominio verificato non significa che HTTPS sia pronto. 5. I controlli si aggiornano ogni 30 secondi per un massimo di dieci minuti mentre questa pagina è visibile. Scegli **Controlla la connessione nuovamente** per riprovare dopo aver modificato DNS o se i controlli automatici sono stati sospesi. 6. Una volta che appare **Il tuo certificato è pronto**, controlla che il tuo CNAME punti al target mostrato e usa **Apri la tua pagina di accesso** per verificare che il tuo portale venga aperto in modo sicuro prima di condividerlo. La prontezza del provider non verifica indipendentemente dove il tuo registrante sta inviando il traffico. Il tuo collegamento al portale esistente rimane disponibile durante l'intera configurazione. Nuovi indirizzi utilizzano la validazione automatica del certificato HTTP. Un controllo di connessione può ripetere in modo sicuro un certificato in sospeso sullo stesso hostname, senza eliminarlo. Le configurazioni TXT più vecchie possono passare alla validazione HTTP quando sono eleggibili. La validazione DNS delegata e wildcard mantiene il loro metodo esistente. Quando è necessaria la validazione DNS, vengono mostrati tutti i valori TXT richiesti, inclusi entrambi i valori quando due record condividono un nome. I record CNAME di delega sono un'alternativa quando offerti. Mantieni i record di delega per i rinnovi; un CNAME e record TXT non possono condividere lo stesso nome. Per la validazione HTTP automatica, ulteriori record di verifica del certificato sono disponibili sotto **Record di verifica del certificato aggiuntivi** invece di essere presentati come un passo extra richiesto. La pagina mostra l'ora dell'ultima verifica e eventuali problemi segnalati dal servizio del certificato. Un tentativo fallito conserva il tuo indirizzo attuale e i record di verifica. Se hai bisogno di aiuto, usa **Ottieni aiuto per collegare il tuo indirizzo**. Non è necessario gestire le credenziali API di TradeCatalog o cercare un pulsante nascosto sulla piattaforma. Lasciare vuoto l'indirizzo salvato e scegliere **Rimuovi l'indirizzo e salva la marca** lo rimuove. Quando la piattaforma è connessa a Cloudflare, l'antico hostname personalizzato viene rimosso anche lì. Non modifica le tue registrazioni DNS del registratore. ## Per gli operatori della piattaforma Le sezioni seguenti descrivono l'infrastruttura di TradeCatalog, non i passaggi che i fornitori devono completare. L'origine di fallback e la route di produzione catch-all sono configurate separatamente. Non modificare le credenziali del provider o le route della zona seguendo la configurazione del fornitore sopra. ## Cloudflare per SaaS Fallo nella zona `tradecatalog.app`, manualmente, quando sei pronto a attivare i domini personalizzati. [Abilita Cloudflare per SaaS](https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/start/enable/) per quella zona prima. ### 1. Origine di fallback Il traffico con hostname personalizzato viene inviato a un'origine di fallback nella tua zona. Per un Worker, questo record è senza origine: | Tipo | Nome | Contenuto | Proxy | | ---- | ---------- | --------- | ------- | | AAAA | `fallback` | `100::` | Proxied | Imposta quindi l'origine di fallback su `fallback.tradecatalog.app`. Nel pannello di controllo è **SSL/TLS → Hostname personalizzati → Origine di fallback**. Con l'API: ``` PUT /zones/{zone_id}/custom_hostnames/fallback_origin { "origin": "fallback.tradecatalog.app" } ``` Aspetta che l'origine di fallback sia **Attiva**. Vedi [Workers come origine di fallback](https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/start/advanced-settings/worker-as-origin/). ### 2. Route Worker Questo è già nelle route **di produzione** in `wrangler.jsonc`. Wrangler sostituisce le route durante il deploy, quindi rimuoverlo lì interromperebbe il raggiungimento del Worker da parte del dominio del fornitore. Non aggiungerlo alla fase di staging. ```json { "pattern": "*/*", "zone_name": "tradecatalog.app" } ``` Questa route invia ogni host che entra nella zona a questo Worker, incluso il dominio del cliente. Le route più specifiche vincono, quindi lascia le route che sono già presenti: ```json { "pattern": "tradecatalog.app", "custom_domain": true } ``` ```json { "pattern": "*.tradecatalog.app/*", "zone_name": "tradecatalog.app" } ``` Lascia la route del Worker di staging come è: ```json { "pattern": "staging.tradecatalog.app", "custom_domain": true } ``` Non aggiungere `*/*` in staging. Non creare un hostname personalizzato uguale a `tradecatalog.app`, `www.tradecatalog.app` o `fallback.tradecatalog.app`. ### 3. API hostname personalizzati L'app chiama l'[API hostname personalizzati](https://developers.cloudflare.com/api/resources/custom_hostnames/methods/create/) quando un fornitore verifica un indirizzo, e solo dopo che sono stati impostati sul Worker di produzione: - `CLOUDFLARE_API_TOKEN` come segreto, con permesso di modificare hostname personalizzati e i loro certificati - `CLOUDFLARE_ZONE_ID` come id della zona `tradecatalog.app` ``` POST /zones/{zone_id}/custom_hostnames { "hostname": "portal.theircompany.com", "ssl": { "method": "http", "type": "dv", "settings": { "min_tls_version": "1.2" } } } ``` La polling dello stato utilizza `GET /zones/{zone_id}/custom_hostnames/{id}`. Un controllo di connessione avviato dal fornitore può sicuramente `PATCH` un certificato DV gestito dal provider in sospeso e poi leggere nuovamente il suo stato, preservando le impostazioni SSL. Non elimina mai o ricrea un hostname. I certificati personalizzati attivi e caricati non vengono riavviati, e la validazione delegata o wildcard rimane TXT. Cancellare o sostituire un indirizzo invia `DELETE` per l'id precedente. Nuovi indirizzi utilizzano la validazione del certificato HTTP: una volta che il CNAME punta all'origine di fallback, Cloudflare può validare automaticamente. Gli indirizzi esistenti mantengono il loro metodo di validazione originale fino a quando non viene modificato. Il personale della piattaforma può eseguire **Verifica indirizzo** per qualsiasi azienda dal conto cliente di quell'azienda, e aprendo lo spazio di lavoro e utilizzando Impostazioni → Marchio. **Reimposta la validazione del certificato** è riservato al personale della piattaforma. Richiede a Cloudflare di impostare il metodo del certificato su HTTP. Se Cloudflare non cambia il metodo sull'hostname esistente, l'hostname viene rimosso e creato nuovamente con gli stessi impostazioni di indirizzo e certificato, e il nuovo id viene salvato. La conferma dice che questo cambia l'hostname personalizzato live di Cloudflare. Mentre il reset è in esecuzione, il pulsante di conferma dice Reimpostazione…, mostra un indicatore di caricamento e non può essere premuto nuovamente. Dopo, la pagina mostra lo stato e eventuali registrazioni DNS da inviare al fornitore. Verifica indirizzo sul conto del cliente fa lo stesso mentre la verifica è in corso. Un proprietario di fornitore non può eseguire il reset. Per un indirizzo che continua a utilizzare TXT o delega dopo un retry sicuro, il fornitore sceglie **Verifica connessione nuovamente**, aggiunge ogni record del certificato mostrato sotto **Aggiungi questi record** dal provider DNS, e verifica nuovamente. Il DNS può essere connesso mentre il certificato ha ancora bisogno di questi record. Non sostituire un token TXT con l'altro quando due sono mostrati. Se viene offerta la delega, utilizzare le sue registrazioni CNAME invece delle registrazioni TXT in conflitto. L'app non reindirizza `/.well-known/acme-challenge/` o `/.well-known/pki-validation/` su quel host. Lasciare quei percorsi intatti in qualsiasi regola di reindirizzamento, in modo che la verifica del certificato non venga riscritta. ### Ciò che il cliente aggiunge Un CNAME per `portal.theircompany.com` (o `order.`) che punta a `fallback.tradecatalog.app`. Consigliamo di utilizzare questo nome. Un dominio base come `theircompany.com` non può essere un CNAME normale senza spostare la posta e la proxying dell'apice di Cloudflare è una configurazione separata. Non utilizzarlo.