Configurare Sitecore Content Hub DAM in SitecoreAI: guida pratica, errori comuni e cose da verificare

Integrare Sitecore Content Hub DAM con SitecoreAI sembra, sulla carta, una configurazione abbastanza lineare: abiliti il connettore, aggiungi qualche variabile, configuri CORS e fai deploy. Nella pratica, però, ci sono almeno tre livelli diversi che devono essere allineati: SitecoreAI Deploy, Content Hub e il browser.

Questo articolo raccoglie una checklist pratica per chi deve configurare il DAM connector e vuole evitare alcune trappole abbastanza comuni.

1. Capire i due flussi: Pages e Content Editor

La prima cosa importante è non dare per scontato che Pages e Content Editor si comportino nello stesso modo.

In Pages, il DAM viene aperto dentro il contesto di:

https://pages.sitecorecloud.io

Nel Content Editor, invece, il DAM viene aperto dal dominio del CM, per esempio:

https://xmc-my-environment.sitecorecloud.io

Questa differenza è fondamentale. Può capitare che il DAM funzioni in Pages ma non nel Content Editor, anche se la configurazione sembra la stessa. Il motivo è che Content Hub deve permettere origini diverse.

2. Variabili da configurare in SitecoreAI Deploy

Nel progetto SitecoreAI Deploy, sull'ambiente interessato, vanno configurate le variabili lato CM. Le principali sono:

SITECORE_AppSettings_damEnabled__define = yes

Sitecore_ConnectionStrings_DAM_dot_SearchPage =
https://<content-hub-host>/en-us/sitecore-dam-connect/approved-assets

Sitecore_ConnectionStrings_DAM_dot_ExternalRedirectKey = Sitecore

Sitecore_ConnectionStrings_DAM_dot_ContentHub =
ClientId=<client-id>;ClientSecret=<client-secret>;UserName=<username>;Password=<password>;URI=https://<content-hub-host>/;

Consiglio pratico: attenzione agli spazi. La connection string deve essere pulita, senza spazi dopo = o tra i separatori ;.

Dopo aver modificato queste variabili, non basta "sperare" che vengano lette subito: va eseguito un nuovo deploy, o comunque applicato il processo previsto per farle arrivare al CM.

3. Utente tecnico Content Hub: a cosa serve davvero

Creare un utente tecnico in Content Hub ha senso, ma bisogna capire a cosa serve.

Serve per autenticare Sitecore verso Content Hub tramite la connection string:

UserName=<technical-user>
Password=<password>

Non serve invece a risolvere problemi di CORS, CSP o iframe. Quelli sono legati alla configurazione del tenant Content Hub e del CM, non ai permessi del singolo utente.

Quindi, se vedete un errore tipo:

X-Frame-Options: deny

non state guardando un problema di permessi utente. State guardando un blocco lato Content Hub/browser.

4. CORS in Content Hub

In Content Hub bisogna aggiungere le origini che devono usare il DAM connector. Tipicamente:

https://pages.sitecorecloud.io/
https://<xmc-environment-host>.sitecorecloud.io/

Per esempio:

https://pages.sitecorecloud.io/
https://xmc-my-qa-environment.sitecorecloud.io/

Se usate Pages staging, valutate anche:

https://pages-staging.sitecore-staging.cloud/

Nota pratica: aggiungete sempre l'host corretto dell'ambiente specifico. DEV, QA e PROD non sono intercambiabili.

5. CSP del Content Editor

Il Content Editor deve poter caricare Content Hub dentro un iframe. Se il browser blocca con un errore del tipo:

violates the following Content Security Policy directive: "frame-src ..."

allora il problema è probabilmente lato CSP del CM. In quel caso serve aggiungere il dominio Content Hub alla Content-Security-Policy, ad esempio:

frame-src 'self'
  https://*.sitecore-staging.cloud/auth
  https://*.sitecorecloud.io/auth
  https://<content-hub-host>

Nel nostro caso abbiamo gestito questa parte tramite XDT su web.config.

Se usate XDT, valutate bene Replace rispetto a Remove + Insert. Replace funziona se l'header esiste già:

xdt:Locator="Match(name)"
xdt:Transform="Replace"

Se però l'header non esiste nell'ambiente target, Replace non aggiunge nulla. Per ambienti non perfettamente allineati, una strategia Remove + Insert può essere più robusta.

6. Non confondere CORS, CSP e X-Frame-Options

Questa è probabilmente la parte più importante.

Nell'ultimo caso il blocco arriva da Content Hub: non lo risolvete dal frontend e non lo risolvete aggiungendo permessi all'utente tecnico.

7. Come verificare velocemente

Nel Content Editor:

1. Aprite i DevTools.
2. Cliccate "Browse Sitecore DAM".
3. Guardate la console.
4. Guardate la request verso Content Hub nel tab Network.
5. Controllate i Response Headers.

In particolare cercate:

• Content-Security-Policy
• X-Frame-Options
• Access-Control-Allow-Origin

Questi header raccontano quasi sempre dove si trova il problema.

8. Checklist finale

Prima di considerare chiusa la configurazione, verificate:

Conclusione

La configurazione del DAM connector non è difficile, ma coinvolge più componenti e gli errori del browser possono trarre in inganno.

Il trucco è leggere bene il tipo di blocco:

• CORS significa problema di origine per chiamate HTTP.
• CSP significa che il CM non permette quel frame.
• X-Frame-Options significa che Content Hub non vuole essere caricato in iframe da quel contesto.

Una volta separati questi livelli, il troubleshooting diventa molto più semplice.

Riferimenti utili

• Enable the DAM connector in an environment deployed to SitecoreAI
• Configure the Sitecore Connect for Content Hub connector