{"id":4906,"date":"2026-04-23T16:08:35","date_gmt":"2026-04-23T14:08:35","guid":{"rendered":"https:\/\/punchoutrocket.com\/por-que-su-tienda-online-falla-en-sap-ariba-y-como-punchout-rocket-lo-soluciona-en-silencio\/"},"modified":"2026-04-24T12:14:10","modified_gmt":"2026-04-24T10:14:10","slug":"por-que-falla-en-sap-ariba-y-como-punchout-rocket-lo-soluciona","status":"publish","type":"post","link":"https:\/\/punchoutrocket.com\/es\/por-que-falla-en-sap-ariba-y-como-punchout-rocket-lo-soluciona\/","title":{"rendered":"\u00bfPor qu\u00e9 su tienda online falla en SAP Ariba y c\u00f3mo PunchOut Rocket lo soluciona en silencio?"},"content":{"rendered":"
\n

\u00bfPor qu\u00e9 su tienda online falla en SAP Ariba y c\u00f3mo PunchOut Rocket lo soluciona en silencio?<\/strong><\/h1>\n<\/div><\/section>\n

Ha configurado su tienda online de WooCommerce, Magento, nopCommerce o personalizada a la perfecci\u00f3n. Productos, precios, proceso de compra: todo funciona. Pero entonces, un cliente empresarial importante le pide que conecte su tienda a SAP Ariba para PunchOut, y de repente todo se rompe: iFrames en blanco, sesiones cerradas, carritos de compra invisibles. Ning\u00fan mensaje de error lo explica claramente. Este art\u00edculo desglosa exactamente lo que ocurre a nivel del navegador, por qu\u00e9 los sitios de comercio electr\u00f3nico est\u00e1ndar son estructuralmente incompatibles con la forma en que las plataformas de eProcurement cargan las tiendas de los proveedores, y c\u00f3mo la t\u00e9cnica de proxy inverso de PunchOut Rocket elimina todos estos problemas autom\u00e1ticamente, sin tocar la configuraci\u00f3n de su servidor.<\/p>\n<\/div><\/section>\n

C\u00f3mo las plataformas de eProcurement cargan las tiendas de los proveedores<\/strong><\/h2>\n

Cuando un comprador que trabaja en SAP Ariba, Coupa, Jaggaer, Oracle iProcurement<\/strong> o cualquier sistema de adquisici\u00f3n empresarial similar hace clic en el bot\u00f3n \u00abComprar ahora\u00bb de un proveedor, no abandona su portal. La plataforma de adquisici\u00f3n abre la tienda online del proveedor dentro de un iFrame HTML<\/strong> incrustado directamente en su propia interfaz. <\/p>\n

Este dise\u00f1o tiene sentido desde la perspectiva del flujo de trabajo: el comprador nunca pierde el contexto dentro de su herramienta interna, las aprobaciones y las comprobaciones de presupuesto permanecen bajo la jurisdicci\u00f3n del sistema de adquisici\u00f3n, y toda la sesi\u00f3n \u2014desde la navegaci\u00f3n hasta la transferencia del carrito\u2014 est\u00e1 contenida dentro de una \u00fanica interfaz auditable.<\/p>\n

Lo que los equipos de compras no siempre anuncian es que este dise\u00f1o de iFrame impone estrictos requisitos de seguridad a nivel de navegador en el sitio web del proveedor. Requisitos que la mayor\u00eda de las tiendas online est\u00e1ndar no est\u00e1n configuradas para cumplir, porque nunca fueron dise\u00f1adas para cargarse como subdocumentos incrustados dentro de una aplicaci\u00f3n de terceros. <\/p>\n

\u00bfQu\u00e9 es un iFrame?<\/strong> Un <iframe><\/em> es un elemento HTML que incrusta una p\u00e1gina web dentro de otra. La p\u00e1gina principal (el portal de compras) y la p\u00e1gina incrustada (su tienda online) son tratadas por el navegador como or\u00edgenes completamente separados, lo que activa una serie de pol\u00edticas de seguridad de origen cruzado que pueden bloquear silenciosamente el funcionamiento de su tienda. <\/p>\n

Los dos principales modos de fallo que resultan de esta arquitectura son una violaci\u00f3n de frame-ancestors de la Pol\u00edtica de Seguridad de Contenido<\/strong> y un rechazo de cookies SameSite<\/strong>. Comprender ambos es esencial para entender por qu\u00e9 un middleware simple que enruta las solicitudes a trav\u00e9s de un proxy inverso lo resuelve todo de una sola vez.<\/p>\n<\/div><\/section>\n

El error frame-ancestors explicado<\/strong><\/h2>\n

Los servidores web modernos pueden instruir a los navegadores sobre qu\u00e9 or\u00edgenes externos tienen permiso para incrustar sus p\u00e1ginas dentro de un iFrame. Esta instrucci\u00f3n se entrega a trav\u00e9s de una cabecera de respuesta HTTP llamada Content Security Policy<\/strong>, espec\u00edficamente su directiva frame-ancestors<\/em>. <\/p>\n

Cuando un navegador carga una p\u00e1gina dentro de un iFrame, comprueba la cabecera Content-Security-Policy: frame-ancestors<\/em> devuelta por el servidor de la p\u00e1gina incrustada. Si el origen del sitio incrustador no est\u00e1 listado en esa directiva, el navegador se niega a renderizar la p\u00e1gina. Usted ve un iFrame en blanco. No aparece ning\u00fan mensaje de error en la tienda. El comprador simplemente no ve nada. <\/p>\n

Lo que el servidor realmente env\u00eda:<\/strong> La mayor\u00eda de los proveedores de alojamiento y las gu\u00edas de endurecimiento de servidores recomiendan establecer una pol\u00edtica restrictiva de frame-ancestors<\/em> como medida de seguridad contra ataques de clickjacking. Una configuraci\u00f3n t\u00edpica bloqueada se ve as\u00ed: Content-Security-Policy: frame-ancestors ‘self’<\/em>. Esto le dice a cada navegador que solo la propia p\u00e1gina tiene permiso para incrustar este sitio en un iFrame. Cualquier portal de eProcurement que intente cargar su tienda obtendr\u00e1 un marco en blanco. <\/p>\n

El equivalente m\u00e1s antiguo es la cabecera X-Frame-Options: SAMEORIGIN<\/em> o X-Frame-Options: DENY<\/em>, que se comporta de forma id\u00e9ntica pero con menos granularidad. Si su servidor env\u00eda cualquiera de estas sin incluir expl\u00edcitamente el dominio de la plataforma de compras en la lista blanca, su sesi\u00f3n de PunchOut mostrar\u00e1 un iFrame en blanco. <\/p>\n

Para solucionar esto manualmente sin un proxy inverso, debe identificar cada dominio de plataforma de compras que utilizan sus clientes \u2014que puede variar por cliente\u2014 y a\u00f1adir cada uno a su directiva frame-ancestors<\/em>. Para un proveedor que atiende a cinco clientes diferentes a trav\u00e9s de Ariba, Coupa y Jaggaer, esto significa mantener una configuraci\u00f3n de servidor que liste potencialmente docenas de dominios, manteni\u00e9ndola actualizada cada vez que un cliente migra de plataforma o cambia su subdominio de portal. <\/p>\n

El impacto en el mundo real:<\/strong> Un iFrame en blanco durante una sesi\u00f3n de PunchOut no genera un ticket de soporte como lo har\u00eda un error 500. Los compradores simplemente informan de que \u00abla tienda del proveedor no funciona\u00bb y los equipos de compras a menudo dedican horas a solucionar lo que en realidad es una \u00fanica cabecera HTTP faltante en el servidor web del proveedor.<\/p>\n<\/div><\/section>\n

El problema de las cookies SameSite explicado<\/strong><\/h2>\n

Incluso si configura correctamente frame-ancestors<\/em> para permitir que el portal de compras incruste su tienda, existe un segundo problema, m\u00e1s insidioso: las cookies de origen cruzado est\u00e1n bloqueadas por defecto en todos los navegadores modernos<\/strong>.<\/p>\n

Su plataforma de comercio electr\u00f3nico depende en gran medida de las cookies para mantener el estado de la sesi\u00f3n: saber qui\u00e9n ha iniciado sesi\u00f3n, qu\u00e9 hay en el carrito, qu\u00e9 lista de precios aplicar y si un usuario est\u00e1 autenticado. Estas cookies son establecidas por su servidor y enviadas de vuelta al navegador con cada solicitud. <\/p>\n

En 2020, Google Chrome (seguido r\u00e1pidamente por Firefox y Edge) cambi\u00f3 el comportamiento predeterminado de las cookies en contextos de origen cruzado. El cambio, regido por el atributo de cookie SameSite<\/strong>, funciona as\u00ed: <\/p>\n

    \n
  • SameSite=Lax (predeterminado) – Cookies bloqueadas en iFrames:<\/strong> Cualquier cookie sin un atributo SameSite expl\u00edcito es tratada como Lax por los navegadores modernos. Las cookies Lax no se env\u00edan en solicitudes de subrecursos de origen cruzado, lo que incluye los iFrames. Su tienda se abre dentro de Ariba, pero la cookie de sesi\u00f3n se descarta silenciosamente. <\/li>\n
  • SameSite=None; Secure – Lo que debe configurar:<\/strong> Para permitir que las cookies se env\u00eden dentro de un iFrame de origen cruzado, cada cookie de sesi\u00f3n y de autenticaci\u00f3n debe llevar expl\u00edcitamente tanto SameSite=None como la bandera Secure. Omitir cualquiera de los atributos hace que el navegador descarte la cookie. <\/li>\n<\/ul>\n

    La consecuencia pr\u00e1ctica es grave: incluso cuando el iFrame se renderiza visualmente, el comprador puede aparecer como un invitado an\u00f3nimo y con la sesi\u00f3n cerrada. La lista de precios dedicada clonada para ellos es inaccesible. El carrito no puede asociarse con su sesi\u00f3n. El proceso de compra se rompe por completo. La sesi\u00f3n de PunchOut no devuelve ning\u00fan art\u00edculo al sistema de compras. <\/p>\n

    Por qu\u00e9 esto es especialmente dif\u00edcil de solucionar en WooCommerce y Magento:<\/strong> Tanto WooCommerce como Magento establecen numerosas cookies de sesi\u00f3n y autenticaci\u00f3n. Muchas son establecidas por los manejadores de sesi\u00f3n de PHP, algunas por la propia capa de autenticaci\u00f3n de la plataforma, y otras por plugins de terceros. No existe un \u00fanico interruptor que aplique SameSite=None; Secure<\/em> a todas ellas a la vez. La soluci\u00f3n requiere cambios en la configuraci\u00f3n de PHP a nivel de servidor, c\u00f3digo personalizado o una combinaci\u00f3n de ambos, y debe validarse en todos los navegadores que utilizan sus compradores. <\/p>\n

    HTTPS es innegociable:<\/strong> El atributo SameSite=None<\/em> solo es respetado por los navegadores cuando la cookie tambi\u00e9n est\u00e1 marcada como Secure<\/em>, lo que significa que solo puede enviarse a trav\u00e9s de conexiones HTTPS. Si alguna parte de su tienda o configuraci\u00f3n de servidor sirve contenido a trav\u00e9s de HTTP, la cookie ser\u00e1 rechazada de todos modos. Aseg\u00farese de que todo su sitio se ejecuta bajo un certificado TLS v\u00e1lido.<\/p>\n<\/div><\/section>\n

    Por qu\u00e9 estos errores son tan dif\u00edciles de depurar<\/strong><\/h2>\n

    Tanto la violaci\u00f3n de frame-ancestors<\/em> como el rechazo de cookies SameSite<\/em> son silenciosos desde la perspectiva del usuario. El comprador no ve una p\u00e1gina de error descriptiva. La tienda del proveedor puede renderizarse parcialmente. La consola de desarrollador del navegador muestra el error real, pero los compradores y los administradores de compras no abren las herramientas de desarrollo. <\/p>\n

    \u00abEl PunchOut del proveedor no funciona\u00bb es casi siempre un error de pol\u00edtica de seguridad del navegador, invisible para los usuarios, trivial de diagnosticar con las herramientas adecuadas, pero sorprendentemente dif\u00edcil de solucionar sin acceso a nivel de servidor.<\/em><\/p>\n

    Desde la perspectiva del soporte, estos problemas son particularmente costosos porque:<\/p>\n

      \n
    • No son reproducibles de forma aislada<\/strong>: su tienda funciona bien cuando se visita directamente; solo falla cuando se incrusta en el dominio de un portal de compras espec\u00edfico.<\/li>\n
    • Dependen de la versi\u00f3n del navegador<\/strong>: las versiones antiguas de Chrome o Firefox pueden haber sido m\u00e1s permisivas, lo que lleva a informes intermitentes.<\/li>\n
    • Requieren acceso al servidor para solucionarse<\/strong>: un proveedor que utiliza alojamiento compartido o una plataforma gestionada puede que ni siquiera tenga permiso para establecer cabeceras de respuesta HTTP personalizadas.<\/li>\n
    • Se multiplican con cada nuevo cliente<\/strong>: cada plataforma de compras tiene un dominio de portal diferente, lo que requiere un mantenimiento continuo de la lista blanca de su servidor.<\/li>\n<\/ul>\n

      La soluci\u00f3n correcta no es parchear cada s\u00edntoma individualmente en cada tienda. La soluci\u00f3n correcta es eliminar por completo la carga de iFrames de origen cruzado, que es exactamente lo que hace el proxy inverso de PunchOut Rocket.<\/p>\n<\/div><\/section>\n

      Proxy inverso de PunchOut Rocket: c\u00f3mo funciona<\/strong><\/h2>\n

      El modo de funcionamiento predeterminado y recomendado de PunchOut Rocket utiliza una arquitectura de proxy inverso<\/strong> para servir su tienda online durante las sesiones de PunchOut. Comprender lo que esto significa en la pr\u00e1ctica explica por qu\u00e9 elimina tanto los problemas de frame-ancestors<\/em> como los de SameSite<\/em> en una \u00fanica decisi\u00f3n arquitect\u00f3nica. <\/p>\n

      El principio:<\/strong> Un proxy inverso se sit\u00faa entre el cliente (el navegador del comprador) y el servidor de origen (su tienda online). En lugar de que el navegador cargue su tienda directamente, realiza solicitudes a la infraestructura de PunchOut Rocket, que luego obtiene el contenido de su tienda en nombre del navegador y lo devuelve como si fuera contenido propio de PunchOut Rocket. <\/p>\n

      Desde la perspectiva del navegador, toda la sesi\u00f3n de PunchOut \u2014el cat\u00e1logo de productos, el carrito, el flujo de pago\u2014 proviene de un \u00fanico origen consistente: el dominio de PunchOut Rocket<\/strong>. No hay iFrame de origen cruzado. No hay cookies de terceros. La cabecera frame-ancestors<\/em> es controlada por la infraestructura de PunchOut Rocket, que ya permite los portales de eProcurement. Todas las cookies se establecen y leen bajo el origen de PunchOut Rocket y se tratan como de primera parte. <\/p>\n

      Flujo de sesi\u00f3n con proxy inverso habilitado:<\/strong><\/p>\n

        \n
      • 1. El comprador hace clic en \u00abPunchOut\u00bb en Ariba o Coupa:<\/strong> El sistema de eProcurement env\u00eda una solicitud de configuraci\u00f3n cXML u OCI al punto final de PunchOut Rocket.<\/li>\n
      • 2. PunchOut Rocket autentica la sesi\u00f3n:<\/strong> Se verifican las credenciales, se resuelve la identidad correcta del comprador y se genera un token de sesi\u00f3n seguro. PunchOut Rocket inicia sesi\u00f3n en su tienda online utilizando la cuenta de usuario clonada configurada para este Cliente Final. <\/li>\n
      • 3. El proxy inverso comienza a servir su tienda:<\/strong> El navegador del comprador es dirigido a una URL de PunchOut Rocket. Todas las solicitudes posteriores de p\u00e1ginas, activos y llamadas a la API se env\u00edan a trav\u00e9s de la infraestructura de PunchOut Rocket. La URL de su tienda nunca aparece en la barra de direcciones del navegador durante la sesi\u00f3n. <\/li>\n
      • 4. Las cookies, cabeceras y activos se reescriben:<\/strong> PunchOut Rocket reescribe las cabeceras de respuesta y los dominios de las cookies para que todo se sirva bajo un \u00fanico origen consistente. No se aplica ninguna pol\u00edtica SameSite entre or\u00edgenes porque solo hay un origen. No se necesita una lista blanca de frame-ancestors en su servidor porque la infraestructura de PunchOut Rocket se encarga de ello. <\/li>\n
      • 5. El comprador compra y env\u00eda el carrito:<\/strong> El contenido del carrito es interceptado por PunchOut Rocket, convertido al formato cXML u OCI correcto, y transmitido de vuelta al sistema de compras como una solicitud de compra correctamente estructurada.<\/li>\n<\/ul>\n

        No se requiere configuraci\u00f3n del servidor:<\/strong> Con el proxy inverso habilitado, no necesita modificar ninguna cabecera HTTP, pol\u00edticas de cookies o archivos de configuraci\u00f3n del servidor en su host de comercio electr\u00f3nico. La infraestructura de PunchOut Rocket gestiona toda la compatibilidad de origen cruzado en su nombre. Esto es v\u00e1lido independientemente de si sus clientes utilizan Ariba, Coupa, Jaggaer o cualquier otro portal.<\/p>\n<\/div><\/section>\n

        Interferencia de plugins: qu\u00e9 puede romper el proxy<\/strong><\/h2>\n

        El proxy inverso funciona obteniendo el HTML de su tienda en tiempo real y retransmiti\u00e9ndolo al navegador del comprador. Esto significa que el HTML que produce su servidor debe ser limpio y resoluble por URL: cada etiqueta de script, referencia de hoja de estilo y origen de imagen debe utilizar rutas URL est\u00e1ndar absolutas o relativas que PunchOut Rocket pueda reescribir correctamente. <\/p>\n

        Una clase de plugins de WordPress y WooCommerce rompe esta suposici\u00f3n: los plugins de minificaci\u00f3n de HTML y optimizaci\u00f3n de activos<\/strong>.<\/p>\n

        El problema de la codificaci\u00f3n Base64:<\/strong> Plugins como Autoptimize<\/strong> mejoran el rendimiento de la p\u00e1gina concatenando y minificando archivos CSS y JavaScript. En sus configuraciones m\u00e1s agresivas, tambi\u00e9n incrustan el contenido concatenado como URIs de datos codificados en Base64<\/strong> directamente en el HTML. En lugar de un enlace a una hoja de estilo como: <link rel=\u00bbstylesheet\u00bb href=\u00bb\/wp-content\/cache\/autoptimize\/css\/autoptimize_abc123.css\u00bb><\/em>, la salida se convierte en algo como: <style>@import url(\u00abdata:text\/css;base64,Ym9keXt……\u00bb)<\/style><\/em>.<\/p>\n

        Cuando el proxy inverso retransmite este HTML, esas URIs de datos codificadas en Base64 no tienen una URL que reescribir; son blobs opacos de contenido codificado. Cualquier activo referenciado dentro de ellas (im\u00e1genes de fondo, fuentes web, importaciones adicionales) se resuelve contra el origen incorrecto o no se carga en absoluto. El resultado es una tienda con estilos rotos, fuentes faltantes, botones invisibles y un dise\u00f1o no funcional dentro del iFrame de compras. <\/p>\n

        Plugins que pueden interferir:<\/strong><\/p>\n

          \n
        • Autoptimize:<\/strong> Especialmente cuando \u00abInline and Defer CSS\u00bb o \u00abInline all CSS\u00bb est\u00e1 habilitado. El plugin completo debe deshabilitarse durante las sesiones de PunchOut. <\/li>\n
        • WP Rocket:<\/strong> Las opciones \u00abCombine CSS Files\u00bb y \u00abCombine JavaScript Files\u00bb pueden causar problemas. Deshabilite solo las opciones de combinar\/incrustar activos. <\/li>\n
        • LiteSpeed Cache:<\/strong> La minificaci\u00f3n de HTML y la configuraci\u00f3n de combinaci\u00f3n de CSS\/JS deben deshabilitarse. El almacenamiento en cach\u00e9 b\u00e1sico de p\u00e1ginas no afecta el comportamiento del proxy. <\/li>\n
        • W3 Total Cache:<\/strong> El modo \u00abMinify\u00bb para CSS y JS puede producir activos codificados en l\u00ednea. Deshabilite la minificaci\u00f3n, pero conserve el almacenamiento en cach\u00e9 de objetos\/p\u00e1ginas si es necesario. <\/li>\n
        • Plugins de cach\u00e9 de p\u00e1gina est\u00e1ndar:<\/strong> Los plugins que almacenan en cach\u00e9 p\u00e1ginas HTML completas sin alterar la estructura de URL de los activos son generalmente seguros.<\/li>\n<\/ul>\n

          C\u00f3mo diagnosticar un conflicto de plugins:<\/strong><\/p>\n

            \n
          1. Abra la sesi\u00f3n de PunchOut en un navegador y utilice Ver c\u00f3digo fuente de la p\u00e1gina<\/strong> (no el inspector de elementos de DevTools, que muestra el DOM en vivo).<\/li>\n
          2. Busque en el HTML sin procesar la cadena data:text\/css;base64,<\/em> o data:application\/javascript;base64,<\/em>.<\/li>\n
          3. Si se encuentra, un plugin de minificaci\u00f3n est\u00e1 codificando activos en l\u00ednea. Identifique qu\u00e9 plugin es el responsable a partir de sus comentarios de salida en el c\u00f3digo fuente. <\/li>\n
          4. Deshabilite ese plugin (o su funci\u00f3n de codificaci\u00f3n en l\u00ednea) y vuelva a probar la sesi\u00f3n de PunchOut.<\/li>\n<\/ol>\n

            Nota de rendimiento:<\/strong> Deshabilitar Autoptimize o plugins similares no significa sacrificar el rendimiento del sitio para los visitantes habituales. La mayor\u00eda de los hosts y CDN modernos proporcionan multiplexaci\u00f3n HTTP\/2 que hace que la concatenaci\u00f3n de archivos sea en gran medida innecesaria.<\/p>\n<\/div><\/section>\n

            Deshabilitar el proxy inverso: lo que debe configurar manualmente<\/strong><\/h2>\n

            El proxy inverso est\u00e1 habilitado por defecto<\/strong> para todos los sitios de PunchOut Rocket y es la configuraci\u00f3n m\u00e1s recomendada. Sin embargo, si el proxy inverso se deshabilita desde la Configuraci\u00f3n Avanzada, la compatibilidad de origen cruzado pasa a ser su responsabilidad. Se aplicar\u00e1n todas las restricciones de seguridad del navegador descritas en este art\u00edculo. Debe configurar lo siguiente en su propio servidor o panel de control de alojamiento: <\/p>\n

            1. Content-Security-Policy: frame-ancestors:<\/strong> Debe listar expl\u00edcitamente cada dominio de plataforma de compras que utilicen sus clientes. La sintaxis de configuraci\u00f3n en su servidor o archivo .htaccess debe seguir este patr\u00f3n:<\/p>\n

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

            # Tambi\u00e9n a\u00f1ada X-Frame-Options para compatibilidad con navegadores antiguos: X-Frame-Options: ALLOW-FROM https:\/\/your-client-portal.ariba.com<\/em><\/p>\n

            Tenga en cuenta que X-Frame-Options<\/em> no admite subdominios comod\u00edn y solo permite un valor de dominio por instancia de cabecera. Para clientes en diferentes subdominios, necesitar\u00e1 l\u00f3gica a nivel de servidor para establecer la cabecera din\u00e1micamente bas\u00e1ndose en la cabecera de solicitud Referer<\/em> u Origin<\/em>. <\/p>\n

            2. Atributos de cookies SameSite:<\/strong> Todas las cookies de sesi\u00f3n y autenticaci\u00f3n deben actualizarse para llevar SameSite=None; Secure<\/em>. En una pila de WordPress\/WooCommerce que ejecuta PHP, el enfoque m\u00e1s fiable es establecer esto globalmente a nivel de PHP: <\/p>\n

            session.cookie_samesite = \u00abNone\u00bb<\/em><\/p>\n

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

            Verifique que todos los plugins de terceros (pasarelas de pago, an\u00e1lisis, gestores de sesi\u00f3n) tambi\u00e9n utilicen SameSite=None; Secure<\/em> en sus cookies. Una sola cookie no conforme de un plugin puede romper la sesi\u00f3n incluso si las cookies de su plataforma principal est\u00e1n configuradas correctamente. <\/p>\n

            Carga de mantenimiento continuo:<\/strong> Cada nuevo cliente en una nueva plataforma de compras a\u00f1ade otro dominio a su lista blanca de frame-ancestors<\/em>. Las migraciones de plataformas de compras, los nuevos patrones de subdominios y las actualizaciones de seguridad del navegador pueden romper silenciosamente las sesiones existentes sin previo aviso. Esta sobrecarga de mantenimiento es la raz\u00f3n principal por la que PunchOut Rocket habilita el proxy inverso por defecto.<\/p>\n<\/div><\/section>\n

            De un vistazo: Proxy inverso activado vs. desactivado<\/strong><\/h2>\n
              \n
            • frame-ancestors \/ X-Frame-Options:<\/strong> Gestionado por PunchOut Rocket (Proxy activado) vs. Configurar en su servidor (Proxy desactivado).<\/li>\n
            • Cookies SameSite=None; Secure:<\/strong> No existen cookies de origen cruzado (Proxy activado) vs. Deben establecerse en todas las cookies (Proxy desactivado).<\/li>\n
            • Nuevo cliente en una nueva plataforma:<\/strong> Cero cambios de configuraci\u00f3n (Proxy activado) vs. A\u00f1adir nuevo dominio a la lista blanca (Proxy desactivado).<\/li>\n
            • Plugins Autoptimize \/ de incrustaci\u00f3n de activos:<\/strong> Deben deshabilitarse (Proxy activado) vs. No hay proxy que interfiera (Proxy desactivado).<\/li>\n
            • Requisito HTTPS:<\/strong> Impuesto por PunchOut Rocket (Proxy activado) vs. Requerido por SameSite=None (Proxy desactivado).<\/li>\n
            • Acceso al servidor necesario:<\/strong> Ninguno (Proxy activado) vs. Requerido para la configuraci\u00f3n de cabeceras (Proxy desactivado).<\/li>\n
            • Mantenimiento a lo largo del tiempo:<\/strong> Cero (Proxy activado) vs. Continuo por cada nuevo cliente (Proxy desactivado).<\/li>\n<\/ul>\n<\/div><\/section>\n

              Conclusi\u00f3n<\/strong><\/h2>\n

              El muro invisible entre su tienda online y el portal de compras de un comprador no es un error en su c\u00f3digo o en el sistema de su cliente. Es una consecuencia predecible de c\u00f3mo los modelos de seguridad del navegador manejan la incrustaci\u00f3n de iFrames de origen cruzado, y afecta a todos<\/em> los proveedores que intentan conectarse a Ariba, Coupa o Jaggaer con un sitio de comercio electr\u00f3nico est\u00e1ndar. <\/p>\n

              La pol\u00edtica de seguridad de contenido frame-ancestors<\/em> y la restricci\u00f3n de cookies SameSite<\/em> existen por buenas razones: protegen a los usuarios del clickjacking y del seguimiento entre sitios. Pero crean una incompatibilidad genuina con el modelo PunchOut que requiere una soluci\u00f3n estructural, no un parche de configuraci\u00f3n. <\/p>\n

              El proxy inverso de PunchOut Rocket proporciona esa soluci\u00f3n estructural. Al enrutar toda la sesi\u00f3n del comprador a trav\u00e9s de la infraestructura de PunchOut Rocket, el navegador ve un origen \u00fanico y consistente durante toda la sesi\u00f3n. Las restricciones de iFrame de origen cruzado simplemente no se aplican. Las cookies son de primera parte. No se necesita ning\u00fan cambio de configuraci\u00f3n del servidor en su tienda, y no se requiere mantenimiento continuo a medida que incorpora nuevos clientes en nuevas plataformas de compras. <\/p>\n

              La \u00fanica contrapartida es la compatibilidad con plugins: si su pila de WordPress o WooCommerce utiliza herramientas agresivas de minificaci\u00f3n de HTML como Autoptimize con la codificaci\u00f3n en l\u00ednea Base64 habilitada, estas deben deshabilitarse. En la pr\u00e1ctica, esto tiene un impacto insignificante en el rendimiento del sitio regular y es un cambio de configuraci\u00f3n \u00fanico. <\/p>\n

              Para los proveedores que necesitan un control total sobre su entorno de servidor y prefieren gestionar la configuraci\u00f3n de origen cruzado ellos mismos, el proxy puede deshabilitarse, pero los requisitos manuales son sustanciales y aumentan con cada nueva relaci\u00f3n con el cliente. Para la gran mayor\u00eda de los proveedores, el proxy inverso es la opci\u00f3n predeterminada correcta: compatibilidad sin fricciones y sin mantenimiento con cada portal de eProcurement que utilizan sus clientes.<\/p>\n<\/div><\/section>\n<\/div><\/div><\/main><\/div><\/div>