{"id":4903,"date":"2026-04-23T16:08:35","date_gmt":"2026-04-23T14:08:35","guid":{"rendered":"https:\/\/punchoutrocket.com\/perche-il-tuo-negozio-e-commerce-si-blocca-in-sap-ariba-e-come-punchout-rocket-risolve-il-problema-silenziosamente\/"},"modified":"2026-04-24T12:14:10","modified_gmt":"2026-04-24T10:14:10","slug":"perche-e-commerce-si-blocca-in-sap-ariba-e-come-punchout-rocket-risolve","status":"publish","type":"post","link":"https:\/\/punchoutrocket.com\/it\/perche-e-commerce-si-blocca-in-sap-ariba-e-come-punchout-rocket-risolve\/","title":{"rendered":"Perch\u00e9 il tuo negozio e-commerce si blocca in SAP Ariba e come PunchOut Rocket risolve il problema silenziosamente"},"content":{"rendered":"
\n

Perch\u00e9 il tuo negozio e-commerce si blocca in SAP Ariba e come PunchOut Rocket risolve il problema silenziosamente<\/strong><\/h1>\n<\/div><\/section>\n

Hai configurato perfettamente il tuo negozio e-commerce WooCommerce, Magento, nopCommerce o personalizzato. Prodotti, prezzi, checkout: tutto funziona. Poi un importante cliente aziendale ti chiede di collegare il tuo negozio a SAP Ariba per il PunchOut e improvvisamente tutto si blocca: iFrame vuoti, sessioni disconnesse, carrelli della spesa invisibili. Nessun messaggio di errore lo spiega chiaramente. Questo articolo analizza esattamente cosa sta succedendo a livello di browser, perch\u00e9 i siti di e-commerce standard sono strutturalmente incompatibili con il modo in cui le piattaforme di eProcurement caricano i negozi dei fornitori e come la tecnica del reverse proxy di PunchOut Rocket elimina ognuno di questi problemi automaticamente, senza toccare la configurazione del tuo server.<\/p>\n<\/div><\/section>\n

Come le piattaforme di eProcurement caricano i negozi dei fornitori<\/strong><\/h2>\n

Quando un acquirente che lavora all’interno di SAP Ariba, Coupa, Jaggaer, Oracle iProcurement<\/strong> o qualsiasi sistema di approvvigionamento aziendale simile clicca sul pulsante “Acquista ora” di un fornitore, non abbandona il proprio portale. La piattaforma di approvvigionamento apre il negozio e-commerce del fornitore all’interno di un iFrame HTML<\/strong> incorporato direttamente nella propria interfaccia. <\/p>\n

Questo design ha senso dal punto di vista del flusso di lavoro: l’acquirente non perde mai il contesto all’interno del proprio strumento interno, le approvazioni e i controlli del budget rimangono di competenza del sistema di approvvigionamento e l’intera sessione \u2014 dalla navigazione al trasferimento del carrello \u2014 \u00e8 contenuta in un’unica interfaccia verificabile.<\/p>\n

Ci\u00f2 che i team di approvvigionamento non sempre dicono \u00e8 che questo design iFrame impone severi requisiti di sicurezza a livello di browser al sito web del fornitore. Requisiti che la maggior parte dei negozi e-commerce standard non \u00e8 configurata per soddisfare, perch\u00e9 non sono mai stati progettati per essere caricati come sub-documenti incorporati all’interno di un’applicazione di terze parti. <\/p>\n

Cos’\u00e8 un iFrame?<\/strong> Un <iframe><\/em> \u00e8 un elemento HTML che incorpora una pagina web all’interno di un’altra. La pagina principale (il portale di approvvigionamento) e la pagina incorporata (il tuo negozio e-commerce) sono trattate dal browser come origini completamente separate, il che attiva una serie di politiche di sicurezza cross-origin che possono bloccare silenziosamente il funzionamento del tuo negozio. <\/p>\n

Le due principali modalit\u00e0 di errore che derivano da questa architettura sono una violazione frame-ancestors della Content Security Policy<\/strong> e un rifiuto del cookie SameSite<\/strong>. Comprenderli entrambi \u00e8 essenziale per capire perch\u00e9 un semplice middleware che instrada le richieste attraverso un reverse proxy risolve tutto in un colpo solo.<\/p>\n<\/div><\/section>\n

Spiegazione dell’errore frame-ancestors<\/strong><\/h2>\n

I moderni server web possono istruire i browser su quali origini esterne sono autorizzate a incorporare le loro pagine all’interno di un iFrame. Questa istruzione viene fornita tramite un’intestazione di risposta HTTP chiamata Content Security Policy<\/strong>, in particolare la sua direttiva frame-ancestors<\/em>. <\/p>\n

Quando un browser carica una pagina all’interno di un iFrame, controlla l’intestazione Content-Security-Policy: frame-ancestors<\/em> restituita dal server della pagina incorporata. Se l’origine del sito incorporante non \u00e8 elencata in quella direttiva, il browser rifiuta di visualizzare la pagina. Vedrai un iFrame vuoto. Nessun messaggio di errore appare nel negozio. L’acquirente semplicemente non vede nulla. <\/p>\n

Cosa invia effettivamente il server:<\/strong> La maggior parte dei provider di hosting e delle guide alla protezione dei server consiglia di impostare una politica frame-ancestors<\/em> restrittiva come misura di sicurezza contro gli attacchi di clickjacking. Una tipica configurazione bloccata appare cos\u00ec: Content-Security-Policy: frame-ancestors ‘self’<\/em>. Questo dice a ogni browser che solo la pagina stessa \u00e8 autorizzata a incorporare questo sito in un iFrame. Qualsiasi portale di eProcurement che tenta di caricare il tuo negozio riceve un frame vuoto. <\/p>\n

L’equivalente pi\u00f9 vecchio \u00e8 l’intestazione X-Frame-Options: SAMEORIGIN<\/em> o X-Frame-Options: DENY<\/em>, che si comporta in modo identico ma con meno granularit\u00e0. Se il tuo server invia una di queste senza inserire esplicitamente nella whitelist il dominio della piattaforma di approvvigionamento, la tua sessione PunchOut mostrer\u00e0 un iFrame vuoto. <\/p>\n

Per risolvere questo problema manualmente senza un reverse proxy, devi identificare ogni dominio della piattaforma di approvvigionamento utilizzato dai tuoi clienti \u2014 che pu\u00f2 variare per ogni cliente \u2014 e aggiungere ognuno di essi alla tua direttiva frame-ancestors<\/em>. Per un fornitore che serve cinque clienti diversi su Ariba, Coupa e Jaggaer, ci\u00f2 significa mantenere una configurazione del server che elenca potenzialmente decine di domini, mantenendola aggiornata ogni volta che un cliente migra piattaforma o cambia il sottodominio del portale. <\/p>\n

L’impatto nel mondo reale:<\/strong> Un iFrame vuoto durante una sessione PunchOut non genera un ticket di assistenza come farebbe un errore 500. Gli acquirenti riferiscono semplicemente che \u201cil negozio del fornitore non funziona\u201d e i team di approvvigionamento spesso passano ore a cercare di risolvere quello che in realt\u00e0 \u00e8 un singolo header HTTP mancante sul server web del fornitore.<\/p>\n<\/div><\/section>\n

Spiegazione del problema dei cookie SameSite<\/strong><\/h2>\n

Anche se riesci a configurare correttamente frame-ancestors<\/em> per consentire al portale di approvvigionamento di incorporare il tuo negozio, c’\u00e8 un secondo problema pi\u00f9 insidioso: i cookie cross-origin sono bloccati per impostazione predefinita in tutti i browser moderni<\/strong>.<\/p>\n

La tua piattaforma e-commerce si affida pesantemente ai cookie per mantenere lo stato della sessione: sapere chi \u00e8 loggato, cosa c’\u00e8 nel carrello, quale listino prezzi applicare e se un utente \u00e8 autenticato. Questi cookie sono impostati dal tuo server e inviati al browser con ogni richiesta. <\/p>\n

Nel 2020, Google Chrome (seguito rapidamente da Firefox ed Edge) ha cambiato il comportamento predefinito dei cookie nei contesti cross-origin. Il cambiamento, regolato dall’attributo cookie SameSite<\/strong>, funziona cos\u00ec: <\/p>\n

    \n
  • SameSite=Lax (predefinito) – Cookie bloccati negli iFrame:<\/strong> Qualsiasi cookie senza un attributo SameSite esplicito viene trattato come Lax dai browser moderni. I cookie Lax non vengono inviati su richieste di sotto-risorse cross-origin, il che include gli iFrame. Il tuo negozio si apre all’interno di Ariba ma il cookie di sessione viene silenziosamente scartato. <\/li>\n
  • SameSite=None; Secure – Cosa devi impostare:<\/strong> Per consentire l’invio dei cookie all’interno di un iFrame cross-origin, ogni cookie di sessione e di autenticazione deve riportare esplicitamente sia SameSite=None che il flag Secure. L’omissione di uno dei due attributi causa lo scarto del cookie da parte del browser. <\/li>\n<\/ul>\n

    La conseguenza pratica \u00e8 grave: anche quando l’iFrame viene visualizzato visivamente, l’acquirente pu\u00f2 apparire come un ospite anonimo e non loggato. Il listino prezzi dedicato clonato per lui \u00e8 inaccessibile. Il carrello non pu\u00f2 essere associato alla sua sessione. Il checkout si blocca completamente. La sessione PunchOut non restituisce alcun articolo al sistema di approvvigionamento. <\/p>\n

    Perch\u00e9 questo \u00e8 particolarmente difficile da risolvere su WooCommerce e Magento:<\/strong> Sia WooCommerce che Magento impostano numerosi cookie di sessione e di autenticazione. Molti sono impostati dai gestori di sessione PHP, alcuni dal livello di autenticazione della piattaforma stessa e altri da plugin di terze parti. Non esiste un unico interruttore che applichi SameSite=None; Secure<\/em> a tutti contemporaneamente. La soluzione richiede modifiche alla configurazione PHP a livello di server, codice personalizzato o una combinazione di entrambi \u2014 e deve essere convalidata su ogni browser utilizzato dai tuoi acquirenti. <\/p>\n

    L’HTTPS non \u00e8 negoziabile:<\/strong> L’attributo SameSite=None<\/em> viene rispettato dai browser solo quando il cookie \u00e8 contrassegnato anche come Secure<\/em>, il che significa che pu\u00f2 essere inviato solo tramite connessioni HTTPS. Se una qualsiasi parte del tuo negozio o della configurazione del server serve contenuti tramite HTTP, il cookie verr\u00e0 rifiutato a prescindere. Assicurati che l’intero sito funzioni con un certificato TLS valido.<\/p>\n<\/div><\/section>\n

    Perch\u00e9 questi errori sono cos\u00ec difficili da diagnosticare<\/strong><\/h2>\n

    Sia la violazione di frame-ancestors<\/em> che il rifiuto del cookie SameSite<\/em> sono silenziosi dal punto di vista dell’utente. L’acquirente non vede una pagina di errore descrittiva. Il negozio del fornitore potrebbe essere visualizzato parzialmente. La console per sviluppatori del browser mostra l’errore effettivo, ma gli acquirenti e gli amministratori degli approvvigionamenti non aprono i DevTools. <\/p>\n

    \u201cIl PunchOut del fornitore non funziona\u201d \u00e8 quasi sempre un errore della politica di sicurezza del browser \u2014 invisibile agli utenti, banale da diagnosticare con gli strumenti giusti, ma sorprendentemente difficile da risolvere senza accesso a livello di server.<\/em><\/p>\n

    Dal punto di vista dell’assistenza, questi problemi sono particolarmente costosi perch\u00e9:<\/p>\n

      \n
    • Non sono riproducibili isolatamente<\/strong> \u2014 il tuo negozio funziona bene se visitato direttamente; si blocca solo quando \u00e8 incorporato nel dominio di un portale di approvvigionamento specifico.<\/li>\n
    • Dipendono dalla versione del browser<\/strong> \u2014 le versioni pi\u00f9 vecchie di Chrome o Firefox potrebbero essere state pi\u00f9 permissive, portando a segnalazioni intermittenti.<\/li>\n
    • Richiedono l’accesso al server per essere risolti<\/strong> \u2014 un fornitore che utilizza un hosting condiviso o una piattaforma gestita potrebbe non avere nemmeno il permesso di impostare intestazioni di risposta HTTP personalizzate.<\/li>\n
    • Si moltiplicano con ogni nuovo cliente<\/strong> \u2014 ogni piattaforma di approvvigionamento ha un dominio del portale diverso, il che richiede una manutenzione continua della whitelist del tuo server.<\/li>\n<\/ul>\n

      La soluzione corretta non \u00e8 correggere ogni sintomo individualmente su ogni negozio. La soluzione corretta \u00e8 eliminare completamente il caricamento dell’iFrame cross-origin \u2014 che \u00e8 esattamente ci\u00f2 che fa il reverse proxy di PunchOut Rocket.<\/p>\n<\/div><\/section>\n

      Il Reverse Proxy di PunchOut Rocket: come funziona<\/strong><\/h2>\n

      La modalit\u00e0 operativa predefinita e consigliata di PunchOut Rocket utilizza un’architettura reverse proxy<\/strong> per servire il tuo negozio e-commerce durante le sessioni PunchOut. Capire cosa significa in pratica spiega perch\u00e9 elimina sia i problemi di frame-ancestors<\/em> che quelli di SameSite<\/em> con un’unica decisione architettonica. <\/p>\n

      Il principio:<\/strong> Un reverse proxy si interpone tra il client (il browser dell’acquirente) e il server di origine (il tuo negozio e-commerce). Invece di caricare direttamente il tuo negozio, il browser effettua richieste all’infrastruttura di PunchOut Rocket, che poi recupera i contenuti dal tuo negozio per conto del browser e li restituisce come se fossero contenuti propri di PunchOut Rocket. <\/p>\n

      Dal punto di vista del browser, l’intera sessione PunchOut \u2014 il catalogo prodotti, il carrello, il flusso di checkout \u2014 proviene da un’unica origine coerente: il dominio di PunchOut Rocket<\/strong>. Non c’\u00e8 alcun iFrame cross-origin. Non ci sono cookie di terze parti. L’intestazione frame-ancestors<\/em> \u00e8 controllata dall’infrastruttura di PunchOut Rocket, che gi\u00e0 autorizza i portali di eProcurement. Tutti i cookie sono impostati e letti sotto l’origine di PunchOut Rocket e sono trattati come cookie di prima parte. <\/p>\n

      Flusso della sessione con reverse proxy abilitato:<\/strong><\/p>\n

        \n
      • 1. L’acquirente clicca su \u201cPunchOut\u201d in Ariba o Coupa:<\/strong> Il sistema di eProcurement invia una richiesta di configurazione cXML o OCI all’endpoint di PunchOut Rocket.<\/li>\n
      • 2. PunchOut Rocket autentica la sessione:<\/strong> Le credenziali vengono verificate, l’identit\u00e0 corretta dell’acquirente viene risolta e viene generato un token di sessione sicuro. PunchOut Rocket accede al tuo negozio e-commerce utilizzando l’account utente clonato configurato per questo cliente finale. <\/li>\n
      • 3. Il reverse proxy inizia a servire il tuo negozio:<\/strong> Il browser dell’acquirente viene indirizzato a un URL di PunchOut Rocket. Tutte le richieste successive di pagine, risorse e chiamate API vengono inoltrate tramite l’infrastruttura di PunchOut Rocket. L’URL del tuo negozio non appare mai nella barra degli indirizzi del browser durante la sessione. <\/li>\n
      • 4. Cookie, intestazioni e risorse vengono riscritti:<\/strong> PunchOut Rocket riscrive le intestazioni di risposta e i domini dei cookie in modo che tutto venga servito sotto un’unica origine coerente. Nessuna politica SameSite si applica tra origini diverse perch\u00e9 c’\u00e8 una sola origine. Non \u00e8 necessaria alcuna whitelist frame-ancestors sul tuo server perch\u00e9 l’infrastruttura di PunchOut Rocket se ne occupa. <\/li>\n
      • 5. L’acquirente acquista e invia il carrello:<\/strong> Il contenuto del carrello viene intercettato da PunchOut Rocket, convertito nel formato cXML o OCI corretto e trasmesso nuovamente al sistema di approvvigionamento come una richiesta di acquisto correttamente strutturata.<\/li>\n<\/ul>\n

        Zero configurazione del server richiesta:<\/strong> Con il reverse proxy abilitato, non \u00e8 necessario modificare alcuna intestazione HTTP, politica dei cookie o file di configurazione del server sul tuo host e-commerce. L’infrastruttura di PunchOut Rocket gestisce tutta la compatibilit\u00e0 cross-origin per tuo conto. Questo vale indipendentemente dal fatto che i tuoi clienti utilizzino Ariba, Coupa, Jaggaer o qualsiasi altro portale.<\/p>\n<\/div><\/section>\n

        Interferenza dei plugin: cosa pu\u00f2 bloccare il proxy<\/strong><\/h2>\n

        Il reverse proxy funziona recuperando l’HTML del tuo negozio in tempo reale e trasmettendolo al browser dell’acquirente. Ci\u00f2 significa che l’HTML prodotto dal tuo server deve essere pulito e risolvibile tramite URL: ogni tag script, riferimento a fogli di stile e sorgente immagine deve utilizzare percorsi URL assoluti o relativi standard che PunchOut Rocket possa riscrivere correttamente. <\/p>\n

        Una categoria di plugin WordPress e WooCommerce rompe questo presupposto: i plugin di minificazione HTML e ottimizzazione delle risorse<\/strong>.<\/p>\n

        Il problema della codifica Base64:<\/strong> Plugin come Autoptimize<\/strong> migliorano le prestazioni della pagina concatenando e minificando i file CSS e JavaScript. Con le impostazioni pi\u00f9 aggressive, incorporano anche il contenuto concatenato come URI di dati codificati in Base64<\/strong> direttamente nell’HTML. Invece di un link al foglio di stile come: <link rel=”stylesheet” href=”\/wp-content\/cache\/autoptimize\/css\/autoptimize_abc123.css”><\/em>, l’output diventa qualcosa di simile a: <style>@import url(“data:text\/css;base64,Ym9keXt……”)<\/style><\/em>.<\/p>\n

        Quando il reverse proxy trasmette questo HTML, quegli URI di dati codificati in Base64 non hanno un URL da riscrivere \u2014 sono blocchi opachi di contenuto codificato. Qualsiasi risorsa a cui si fa riferimento al loro interno (immagini di sfondo, web font, ulteriori importazioni) si risolve verso l’origine sbagliata o non viene caricata affatto. Il risultato \u00e8 un negozio con stili interrotti, font mancanti, pulsanti invisibili e un layout non funzionante all’interno dell’iFrame di approvvigionamento. <\/p>\n

        Plugin che possono interferire:<\/strong><\/p>\n

          \n
        • Autoptimize:<\/strong> Specialmente quando \u00e8 abilitato \u201cInline and Defer CSS\u201d o \u201cInline all CSS\u201d. L’intero plugin dovrebbe essere disabilitato durante le sessioni PunchOut. <\/li>\n
        • WP Rocket:<\/strong> Le opzioni \u201cCombina file CSS\u201d e \u201cCombina file JavaScript\u201d possono causare problemi. Disabilita solo le opzioni di combinazione\/incorporamento delle risorse. <\/li>\n
        • LiteSpeed Cache:<\/strong> Le impostazioni di minificazione HTML e combinazione CSS\/JS dovrebbero essere disabilitate. La cache di base della pagina non influisce sul comportamento del proxy. <\/li>\n
        • W3 Total Cache:<\/strong> La modalit\u00e0 \u201cMinify\u201d per CSS e JS pu\u00f2 produrre risorse codificate inline. Disabilita la minificazione ma mantieni la cache degli oggetti\/pagine se necessario. <\/li>\n
        • Plugin standard per la cache delle pagine:<\/strong> I plugin che memorizzano nella cache intere pagine HTML senza alterare la struttura degli URL delle risorse sono generalmente sicuri.<\/li>\n<\/ul>\n

          Come diagnosticare un conflitto di plugin:<\/strong><\/p>\n

            \n
          1. Apri la sessione PunchOut in un browser e usa Visualizza sorgente pagina<\/strong> (non l’ispettore degli elementi dei DevTools, che mostra il DOM in tempo reale).<\/li>\n
          2. Cerca nell’HTML grezzo la stringa data:text\/css;base64,<\/em> o data:application\/javascript;base64,<\/em>.<\/li>\n
          3. Se trovata, un plugin di minificazione sta codificando le risorse inline. Identifica quale plugin \u00e8 responsabile dai suoi commenti di output nel sorgente. <\/li>\n
          4. Disabilita quel plugin (o la sua funzione di codifica inline) e testa nuovamente la sessione PunchOut.<\/li>\n<\/ol>\n

            Nota sulle prestazioni:<\/strong> Disabilitare Autoptimize o plugin simili non significa sacrificare le prestazioni del sito per i visitatori abituali. La maggior parte degli host e delle CDN moderni fornisce il multiplexing HTTP\/2 che rende la concatenazione dei file ampiamente non necessaria.<\/p>\n<\/div><\/section>\n

            Disabilitare il Reverse Proxy: cosa devi configurare manualmente<\/strong><\/h2>\n

            Il reverse proxy \u00e8 abilitato per impostazione predefinita<\/strong> per tutti i siti PunchOut Rocket ed \u00e8 la configurazione caldamente consigliata. Tuttavia, se il reverse proxy viene disabilitato dalle Impostazioni avanzate, la compatibilit\u00e0 cross-origin diventa tua responsabilit\u00e0. Si applicher\u00e0 ogni restrizione di sicurezza del browser descritta in questo articolo. Devi configurare quanto segue sul tuo server o sul pannello di controllo dell’hosting: <\/p>\n

            1. Content-Security-Policy: frame-ancestors:<\/strong> Devi elencare esplicitamente ogni dominio della piattaforma di approvvigionamento utilizzato dai tuoi clienti. La sintassi di configurazione nel tuo server o nel file .htaccess dovrebbe seguire questo schema:<\/p>\n

            Content-Security-Policy: frame-ancestors ‘self’ https:\/\/*.ariba.com https:\/\/*.coupahost.com https:\/\/*.jaggaer.com;<\/em><\/p>\n

            # Aggiungi anche X-Frame-Options per la compatibilit\u00e0 con i browser pi\u00f9 vecchi: X-Frame-Options: ALLOW-FROM https:\/\/your-client-portal.ariba.com<\/em><\/p>\n

            Nota che X-Frame-Options<\/em> non supporta i sottodomini jolly e consente un solo valore di dominio per istanza di intestazione. Per i clienti su sottodomini diversi, avrai bisogno di una logica a livello di server per impostare l’intestazione dinamicamente in base all’intestazione della richiesta Referer<\/em> o Origin<\/em>. <\/p>\n

            2. Attributi dei cookie SameSite:<\/strong> Tutti i cookie di sessione e di autenticazione devono essere aggiornati per riportare SameSite=None; Secure<\/em>. Su uno stack WordPress\/WooCommerce che esegue PHP, l’approccio pi\u00f9 affidabile \u00e8 impostarlo globalmente a livello di PHP: <\/p>\n

            session.cookie_samesite = “None”<\/em><\/p>\n

            session.cookie_secure = 1<\/em><\/p>\n

            Verifica che anche tutti i plugin di terze parti (gateway di pagamento, analisi, gestori di sessione) utilizzino SameSite=None; Secure<\/em> sui loro cookie. Un singolo cookie non conforme di un plugin pu\u00f2 interrompere la sessione anche se i cookie della piattaforma principale sono configurati correttamente. <\/p>\n

            Onere di manutenzione continua:<\/strong> Ogni nuovo cliente su una nuova piattaforma di approvvigionamento aggiunge un altro dominio alla tua whitelist frame-ancestors<\/em>. Le migrazioni delle piattaforme di approvvigionamento, i nuovi schemi di sottodomini e gli aggiornamenti della sicurezza del browser possono interrompere silenziosamente le sessioni esistenti senza preavviso. Questo sovraccarico di manutenzione \u00e8 il motivo principale per cui PunchOut Rocket abilita il reverse proxy per impostazione predefinita.<\/p>\n<\/div><\/section>\n

            In sintesi: Reverse Proxy attivo vs. disattivo<\/strong><\/h2>\n
              \n
            • frame-ancestors \/ X-Frame-Options:<\/strong> Gestito da PunchOut Rocket (Proxy abilitato) vs. Da configurare sul tuo server (Proxy disabilitato).<\/li>\n
            • Cookie SameSite=None; Secure:<\/strong> Non esistono cookie cross-origin (Proxy abilitato) vs. Devono essere impostati su tutti i cookie (Proxy disabilitato).<\/li>\n
            • Nuovo cliente su una nuova piattaforma:<\/strong> Zero modifiche alla configurazione (Proxy abilitato) vs. Aggiunta di un nuovo dominio alla whitelist (Proxy disabilitato).<\/li>\n
            • Autoptimize \/ plugin di incorporamento risorse:<\/strong> Devono essere disabilitati (Proxy abilitato) vs. Nessun proxy con cui interferire (Proxy disabilitato).<\/li>\n
            • Requisito HTTPS:<\/strong> Imposto da PunchOut Rocket (Proxy abilitato) vs. Richiesto da SameSite=None (Proxy disabilitato).<\/li>\n
            • Accesso al server necessario:<\/strong> Nessuno (Proxy abilitato) vs. Richiesto per la configurazione degli header (Proxy disabilitato).<\/li>\n
            • Manutenzione nel tempo:<\/strong> Zero (Proxy abilitato) vs. Continua per ogni nuovo cliente (Proxy disabilitato).<\/li>\n<\/ul>\n<\/div><\/section>\n

              Conclusione<\/strong><\/h2>\n

              Il muro invisibile tra il tuo negozio e-commerce e il portale di approvvigionamento di un acquirente non \u00e8 un bug nel tuo codice o nel sistema del tuo cliente. \u00c8 una conseguenza prevedibile di come i modelli di sicurezza del browser gestiscono l’incorporamento di iFrame cross-origin \u2014 e colpisce ogni<\/em> fornitore che tenta di connettersi ad Ariba, Coupa o Jaggaer con un sito e-commerce standard. <\/p>\n

              La policy di sicurezza dei contenuti frame-ancestors<\/em> e la restrizione dei cookie SameSite<\/em> esistono per ottime ragioni: proteggono gli utenti dal clickjacking e dal tracciamento cross-site. Ma creano una reale incompatibilit\u00e0 con il modello PunchOut che richiede una soluzione strutturale, non una patch di configurazione. <\/p>\n

              Il reverse proxy di PunchOut Rocket fornisce quella soluzione strutturale. Instradando l’intera sessione dell’acquirente attraverso l’infrastruttura di PunchOut Rocket, il browser vede un’unica origine coerente per tutta la durata della sessione. Le restrizioni degli iFrame cross-origin semplicemente non si applicano. I cookie sono di prima parte. Non \u00e8 necessaria alcuna modifica alla configurazione del server sul tuo negozio e non \u00e8 richiesta alcuna manutenzione continua man mano che acquisisci nuovi clienti su nuove piattaforme di approvvigionamento. <\/p>\n

              L’unico compromesso \u00e8 la compatibilit\u00e0 dei plugin: se il tuo stack WordPress o WooCommerce utilizza strumenti di minificazione HTML aggressivi come Autoptimize con la codifica inline Base64 abilitata, questi devono essere disabilitati. In pratica, ci\u00f2 ha un impatto trascurabile sulle prestazioni regolari del sito ed \u00e8 una modifica della configurazione da fare una sola volta. <\/p>\n

              Per i fornitori che necessitano di un controllo totale sul proprio ambiente server e preferiscono gestire autonomamente la configurazione cross-origin, il proxy pu\u00f2 essere disabilitato \u2014 ma i requisiti manuali sono sostanziali e crescono con ogni nuova relazione con i clienti. Per la stragrande maggioranza dei fornitori, il reverse proxy \u00e8 l’impostazione predefinita corretta: compatibilit\u00e0 a zero attrito e zero manutenzione con ogni portale di eProcurement utilizzato dai tuoi clienti.<\/p>\n<\/div><\/section>\n<\/div><\/div><\/main><\/div><\/div>