{"id":4888,"date":"2026-04-23T16:08:35","date_gmt":"2026-04-23T14:08:35","guid":{"rendered":"https:\/\/punchoutrocket.com\/dlaczego-twoj-sklep-e-commerce-zawodzi-w-sap-ariba-i-jak-punchout-rocket-naprawia-to-dyskretnie\/"},"modified":"2026-04-24T12:14:11","modified_gmt":"2026-04-24T10:14:11","slug":"dlaczego-sklep-e-commerce-zawodzi-w-sap-ariba-i-jak-punchout-rocket-naprawia","status":"publish","type":"post","link":"https:\/\/punchoutrocket.com\/pl\/dlaczego-sklep-e-commerce-zawodzi-w-sap-ariba-i-jak-punchout-rocket-naprawia\/","title":{"rendered":"Dlaczego Tw\u00f3j sklep e-commerce zawodzi w SAP Ariba i jak PunchOut Rocket naprawia to dyskretnie"},"content":{"rendered":"
\n

Dlaczego Tw\u00f3j sklep e-commerce zawodzi w SAP Ariba i jak PunchOut Rocket naprawia to dyskretnie<\/strong><\/h1>\n<\/div><\/section>\n

Doskonale skonfigurowa\u0142e\u015b sw\u00f3j sklep e-commerce WooCommerce, Magento, nopCommerce lub niestandardowy. Produkty, ceny, proces realizacji zam\u00f3wienia \u2014 wszystko dzia\u0142a. Nast\u0119pnie du\u017cy klient korporacyjny prosi Ci\u0119 o po\u0142\u0105czenie Twojego sklepu z SAP Ariba w celu integracji PunchOut, a nagle wszystko si\u0119 psuje: puste iFrame’y, wylogowane sesje, niewidoczne koszyki. \u017baden komunikat o b\u0142\u0119dzie nie wyja\u015bnia tego jasno. Ten artyku\u0142 szczeg\u00f3\u0142owo opisuje, co dzieje si\u0119 na poziomie przegl\u0105darki, dlaczego standardowe witryny e-commerce s\u0105 strukturalnie niekompatybilne ze sposobem \u0142adowania sklep\u00f3w dostawc\u00f3w przez platformy e-zam\u00f3wie\u0144 oraz jak technika odwrotnego proxy PunchOut Rocket automatycznie eliminuje ka\u017cdy z tych problem\u00f3w \u2014 bez dotykania konfiguracji serwera.<\/p>\n<\/div><\/section>\n

Jak platformy e-zam\u00f3wie\u0144 \u0142aduj\u0105 sklepy dostawc\u00f3w<\/strong><\/h2>\n

Gdy kupuj\u0105cy pracuj\u0105cy w SAP Ariba, Coupa, Jaggaer, Oracle iProcurement<\/strong> lub podobnym korporacyjnym systemie zam\u00f3wie\u0144 klika przycisk \u201eKup teraz\u201d dostawcy, nie opuszcza swojego portalu. Platforma zam\u00f3wie\u0144 otwiera sklep e-commerce dostawcy w iFrame HTML<\/strong> osadzonym bezpo\u015brednio w swoim w\u0142asnym interfejsie. <\/p>\n

Ten projekt ma sens z perspektywy przep\u0142ywu pracy: kupuj\u0105cy nigdy nie traci kontekstu w swoim wewn\u0119trznym narz\u0119dziu, zatwierdzenia i kontrole bud\u017cetu pozostaj\u0105 w jurysdykcji systemu zam\u00f3wie\u0144, a ca\u0142a sesja \u2014 od przegl\u0105dania do przeniesienia koszyka \u2014 jest zawarta w jednym, mo\u017cliwym do audytu interfejsie.<\/p>\n

Czego zespo\u0142y ds. zam\u00f3wie\u0144 nie zawsze reklamuj\u0105, to fakt, \u017ce ten projekt iFrame nak\u0142ada surowe wymagania bezpiecze\u0144stwa na poziomie przegl\u0105darki na witryn\u0119 dostawcy. Wymagania, kt\u00f3rych wi\u0119kszo\u015b\u0107 standardowych sklep\u00f3w e-commerce nie jest w stanie spe\u0142ni\u0107 \u2014 poniewa\u017c nigdy nie zosta\u0142y zaprojektowane do \u0142adowania jako osadzone sub-dokumenty w aplikacji strony trzeciej. <\/p>\n

Co to jest iFrame?<\/strong> <iFrame><\/em> to element HTML, kt\u00f3ry osadza jedn\u0105 stron\u0119 internetow\u0105 w drugiej. Strona nadrz\u0119dna (portal zam\u00f3wie\u0144) i osadzona strona (Tw\u00f3j sklep e-commerce) s\u0105 traktowane przez przegl\u0105dark\u0119 jako ca\u0142kowicie oddzielne \u017ar\u00f3d\u0142a, co wyzwala szereg zasad bezpiecze\u0144stwa cross-origin, kt\u00f3re mog\u0105 po cichu blokowa\u0107 dzia\u0142anie Twojego sklepu. <\/p>\n

Dwa g\u0142\u00f3wne tryby awarii wynikaj\u0105ce z tej architektury to naruszenie dyrektywy frame-ancestors w Content Security Policy<\/strong> oraz odrzucenie pliku cookie SameSite<\/strong>. Zrozumienie obu jest kluczowe do zrozumienia, dlaczego proste oprogramowanie po\u015brednicz\u0105ce, kt\u00f3re kieruje \u017c\u0105dania przez odwrotne proxy, rozwi\u0105zuje wszystko za jednym zamachem.<\/p>\n<\/div><\/section>\n

Wyja\u015bnienie b\u0142\u0119du frame-ancestors<\/strong><\/h2>\n

Nowoczesne serwery internetowe mog\u0105 instruowa\u0107 przegl\u0105darki, kt\u00f3re zewn\u0119trzne \u017ar\u00f3d\u0142a maj\u0105 prawo osadza\u0107 ich strony w iFrame. Ta instrukcja jest dostarczana za po\u015brednictwem nag\u0142\u00f3wka odpowiedzi HTTP o nazwie Content Security Policy<\/strong>, a konkretnie jego dyrektywy frame-ancestors<\/em>. <\/p>\n

Gdy przegl\u0105darka \u0142aduje stron\u0119 w iFrame, sprawdza nag\u0142\u00f3wek Content-Security-Policy: frame-ancestors<\/em> zwr\u00f3cony przez serwer osadzonej strony. Je\u015bli \u017ar\u00f3d\u0142o witryny osadzaj\u0105cej nie jest wymienione w tej dyrektywie, przegl\u0105darka odmawia renderowania strony. Widzisz pusty iFrame. W witrynie sklepu nie pojawia si\u0119 \u017caden komunikat o b\u0142\u0119dzie. Kupuj\u0105cy po prostu nic nie widzi. <\/p>\n

Co faktycznie wysy\u0142a serwer:<\/strong> Wi\u0119kszo\u015b\u0107 dostawc\u00f3w hostingu i przewodnik\u00f3w po zabezpieczaniu serwer\u00f3w zaleca ustawienie restrykcyjnej polityki frame-ancestors<\/em> jako \u015brodka bezpiecze\u0144stwa przeciwko atakom clickjacking. Typowa zablokowana konfiguracja wygl\u0105da nast\u0119puj\u0105co: Content-Security-Policy: frame-ancestors 'self’<\/em>. Informuje to ka\u017cd\u0105 przegl\u0105dark\u0119, \u017ce tylko sama strona mo\u017ce osadza\u0107 t\u0119 witryn\u0119 w iFrame. Ka\u017cdy portal e-zam\u00f3wie\u0144, kt\u00f3ry pr\u00f3buje za\u0142adowa\u0107 Tw\u00f3j sklep, otrzymuje pust\u0105 ramk\u0119. <\/p>\n

Starszym odpowiednikiem jest nag\u0142\u00f3wek X-Frame-Options: SAMEORIGIN<\/em> lub X-Frame-Options: DENY<\/em>, kt\u00f3ry zachowuje si\u0119 identycznie, ale z mniejsz\u0105 szczeg\u00f3\u0142owo\u015bci\u0105. Je\u015bli Tw\u00f3j serwer wysy\u0142a kt\u00f3rykolwiek z nich bez wyra\u017anego umieszczenia domeny platformy zam\u00f3wie\u0144 na bia\u0142ej li\u015bcie, Twoja sesja PunchOut poka\u017ce pusty iFrame. <\/p>\n

Aby naprawi\u0107 to r\u0119cznie bez odwrotnego proxy, musisz zidentyfikowa\u0107 ka\u017cd\u0105 domen\u0119 platformy zam\u00f3wie\u0144, kt\u00f3rej u\u017cywaj\u0105 Twoi klienci \u2014 co mo\u017ce si\u0119 r\u00f3\u017cni\u0107 w zale\u017cno\u015bci od klienta \u2014 i doda\u0107 ka\u017cd\u0105 z nich do dyrektywy frame-ancestors<\/em>. Dla dostawcy obs\u0142uguj\u0105cego pi\u0119ciu r\u00f3\u017cnych klient\u00f3w w Ariba, Coupa i Jaggaer oznacza to utrzymywanie konfiguracji serwera, kt\u00f3ra zawiera potencjalnie dziesi\u0105tki domen, aktualizuj\u0105c j\u0105 za ka\u017cdym razem, gdy klient migruje platformy lub zmienia sw\u00f3j subdomen\u0119 portalu. <\/p>\n

Wp\u0142yw w \u015bwiecie rzeczywistym:<\/strong> Pusty iFrame podczas sesji PunchOut nie generuje zg\u0142oszenia do pomocy technicznej w taki spos\u00f3b, jak b\u0142\u0105d 500. Kupuj\u0105cy po prostu zg\u0142aszaj\u0105, \u017ce \u201esklep dostawcy nie dzia\u0142a\u201d, a zespo\u0142y ds. zam\u00f3wie\u0144 cz\u0119sto sp\u0119dzaj\u0105 godziny na rozwi\u0105zywaniu problem\u00f3w, kt\u00f3re w rzeczywisto\u015bci s\u0105 pojedynczym brakuj\u0105cym nag\u0142\u00f3wkiem HTTP na serwerze internetowym dostawcy.<\/p>\n<\/div><\/section>\n

Wyja\u015bnienie problemu z plikami cookie SameSite<\/strong><\/h2>\n

Nawet je\u015bli pomy\u015blnie skonfigurujesz frame-ancestors<\/em>, aby umo\u017cliwi\u0107 portalowi zam\u00f3wie\u0144 osadzenie Twojego sklepu, istnieje drugi, bardziej podst\u0119pny problem: pliki cookie cross-origin s\u0105 domy\u015blnie blokowane we wszystkich nowoczesnych przegl\u0105darkach<\/strong>.<\/p>\n

Twoja platforma e-commerce w du\u017cym stopniu polega na plikach cookie w celu utrzymania stanu sesji \u2014 wiedz\u0105c, kto jest zalogowany, co znajduje si\u0119 w koszyku, kt\u00f3r\u0105 list\u0119 cen zastosowa\u0107 i czy u\u017cytkownik jest uwierzytelniony. Te pliki cookie s\u0105 ustawiane przez Tw\u00f3j serwer i wysy\u0142ane z powrotem do przegl\u0105darki z ka\u017cdym \u017c\u0105daniem. <\/p>\n

W 2020 roku Google Chrome (szybko za nim Firefox i Edge) zmieni\u0142 domy\u015blne zachowanie plik\u00f3w cookie w kontekstach cross-origin. Zmiana, regulowana przez atrybut pliku cookie SameSite<\/strong>, dzia\u0142a nast\u0119puj\u0105co: <\/p>\n

    \n
  • SameSite=Lax (domy\u015blnie) – Pliki cookie blokowane w iFrame’ach:<\/strong> Ka\u017cdy plik cookie bez jawnego atrybutu SameSite jest traktowany jako Lax przez nowoczesne przegl\u0105darki. Pliki cookie Lax nie s\u0105 wysy\u0142ane w \u017c\u0105daniach sub-zasob\u00f3w cross-origin, co obejmuje iFrame’y. Tw\u00f3j sklep otwiera si\u0119 w Ariba, ale plik cookie sesji jest po cichu usuwany. <\/li>\n
  • SameSite=None; Secure – Co musisz ustawi\u0107:<\/strong> Aby umo\u017cliwi\u0107 wysy\u0142anie plik\u00f3w cookie w iFrame cross-origin, ka\u017cdy plik cookie sesji i uwierzytelniania musi wyra\u017anie zawiera\u0107 zar\u00f3wno SameSite=None, jak i flag\u0119 Secure. Pomini\u0119cie kt\u00f3regokolwiek z atrybut\u00f3w powoduje, \u017ce przegl\u0105darka odrzuca plik cookie. <\/li>\n<\/ul>\n

    Praktyczna konsekwencja jest powa\u017cna: nawet gdy iFrame renderuje si\u0119 wizualnie, kupuj\u0105cy mo\u017ce pojawi\u0107 si\u0119 jako anonimowy, wylogowany go\u015b\u0107. Dedykowana lista cen sklonowana dla niego jest niedost\u0119pna. Koszyk nie mo\u017ce by\u0107 powi\u0105zany z jego sesj\u0105. Proces realizacji zam\u00f3wienia ca\u0142kowicie si\u0119 psuje. Sesja PunchOut nie zwraca \u017cadnych pozycji do systemu zam\u00f3wie\u0144. <\/p>\n

    Dlaczego jest to szczeg\u00f3lnie trudne do naprawienia w WooCommerce i Magento:<\/strong> Zar\u00f3wno WooCommerce, jak i Magento ustawiaj\u0105 liczne pliki cookie sesji i uwierzytelniania. Wiele z nich jest ustawianych przez obs\u0142ug\u0119 sesji PHP, niekt\u00f3re przez w\u0142asn\u0105 warstw\u0119 uwierzytelniania platformy, a inne przez wtyczki stron trzecich. Nie ma jednego prze\u0142\u0105cznika, kt\u00f3ry zastosowa\u0142by SameSite=None; Secure<\/em> do wszystkich z nich jednocze\u015bnie. Naprawa wymaga albo zmian konfiguracji PHP na poziomie serwera, niestandardowego kodu, albo kombinacji obu \u2014 i musi by\u0107 zweryfikowana we wszystkich przegl\u0105darkach u\u017cywanych przez Twoich kupuj\u0105cych. <\/p>\n

    HTTPS jest bezwzgl\u0119dnie wymagane:<\/strong> Atrybut SameSite=None<\/em> jest respektowany przez przegl\u0105darki tylko wtedy, gdy plik cookie jest r\u00f3wnie\u017c oznaczony jako Secure<\/em>, co oznacza, \u017ce mo\u017ce by\u0107 wysy\u0142any tylko przez po\u0142\u0105czenia HTTPS. Je\u015bli jakakolwiek cz\u0119\u015b\u0107 Twojego sklepu lub konfiguracji serwera obs\u0142uguje tre\u015bci przez HTTP, plik cookie zostanie odrzucony niezale\u017cnie od tego. Upewnij si\u0119, \u017ce ca\u0142a Twoja witryna dzia\u0142a z wa\u017cnym certyfikatem TLS.<\/p>\n<\/div><\/section>\n

    Dlaczego te b\u0142\u0119dy s\u0105 tak trudne do debugowania<\/strong><\/h2>\n

    Zar\u00f3wno naruszenie frame-ancestors<\/em>, jak i odrzucenie pliku cookie SameSite<\/em> s\u0105 niewidoczne z perspektywy u\u017cytkownika. Kupuj\u0105cy nie widzi opisowej strony b\u0142\u0119du. Sklep dostawcy mo\u017ce renderowa\u0107 si\u0119 cz\u0119\u015bciowo. Konsola deweloperska przegl\u0105darki pokazuje rzeczywisty b\u0142\u0105d, ale kupuj\u0105cy i administratorzy zam\u00f3wie\u0144 nie otwieraj\u0105 narz\u0119dzi deweloperskich. <\/p>\n

    \u201ePunchOut dostawcy nie dzia\u0142a\u201d to prawie zawsze b\u0142\u0105d polityki bezpiecze\u0144stwa przegl\u0105darki \u2014 niewidoczny dla u\u017cytkownik\u00f3w, trywialny do zdiagnozowania za pomoc\u0105 odpowiednich narz\u0119dzi, ale zaskakuj\u0105co trudny do naprawienia bez dost\u0119pu na poziomie serwera.<\/em><\/p>\n

    Z perspektywy wsparcia technicznego, te problemy s\u0105 szczeg\u00f3lnie kosztowne, poniewa\u017c:<\/p>\n

      \n
    • Nie mo\u017cna ich odtworzy\u0107 w izolacji<\/strong> \u2014 Tw\u00f3j sklep dzia\u0142a dobrze, gdy jest odwiedzany bezpo\u015brednio; psuje si\u0119 tylko wtedy, gdy jest osadzony w domenie konkretnego portalu zam\u00f3wie\u0144.<\/li>\n
    • Zale\u017c\u0105 od wersji przegl\u0105darki<\/strong> \u2014 starsze wersje Chrome lub Firefox mog\u0142y by\u0107 bardziej liberalne, co prowadzi\u0142o do sporadycznych zg\u0142osze\u0144.<\/li>\n
    • Wymagaj\u0105 dost\u0119pu do serwera w celu naprawy<\/strong> \u2014 dostawca korzystaj\u0105cy z hostingu wsp\u00f3\u0142dzielonego lub zarz\u0105dzanej platformy mo\u017ce nawet nie mie\u0107 uprawnie\u0144 do ustawiania niestandardowych nag\u0142\u00f3wk\u00f3w odpowiedzi HTTP.<\/li>\n
    • Mno\u017c\u0105 si\u0119 z ka\u017cdym nowym klientem<\/strong> \u2014 ka\u017cda platforma zam\u00f3wie\u0144 ma inn\u0105 domen\u0119 portalu, co wymaga ci\u0105g\u0142ej konserwacji bia\u0142ej listy serwera.<\/li>\n<\/ul>\n

      Prawid\u0142owym rozwi\u0105zaniem nie jest \u0142atanie ka\u017cdego objawu indywidualnie w ka\u017cdym sklepie. Prawid\u0142owym rozwi\u0105zaniem jest ca\u0142kowite wyeliminowanie \u0142adowania iFrame cross-origin \u2014 co dok\u0142adnie robi odwrotne proxy PunchOut Rocket.<\/p>\n<\/div><\/section>\n

      Odwrotne proxy PunchOut Rocket: Jak to dzia\u0142a<\/strong><\/h2>\n

      Domy\u015blny i zalecany tryb dzia\u0142ania PunchOut Rocket wykorzystuje architektur\u0119 odwrotnego proxy<\/strong> do obs\u0142ugi Twojego sklepu e-commerce podczas sesji PunchOut. Zrozumienie, co to oznacza w praktyce, wyja\u015bnia, dlaczego eliminuje ono zar\u00f3wno problemy z frame-ancestors<\/em>, jak i SameSite<\/em> za pomoc\u0105 jednej decyzji architektonicznej. <\/p>\n

      Zasada:<\/strong> Odwrotne proxy znajduje si\u0119 mi\u0119dzy klientem (przegl\u0105dark\u0105 kupuj\u0105cego) a serwerem \u017ar\u00f3d\u0142owym (Twoim sklepem e-commerce). Zamiast przegl\u0105darki \u0142aduj\u0105cej Tw\u00f3j sklep bezpo\u015brednio, wysy\u0142a ona \u017c\u0105dania do infrastruktury PunchOut Rocket, kt\u00f3ra nast\u0119pnie pobiera zawarto\u015b\u0107 z Twojego sklepu w imieniu przegl\u0105darki i zwraca j\u0105 tak, jakby by\u0142a to w\u0142asna zawarto\u015b\u0107 PunchOut Rocket. <\/p>\n

      Z perspektywy przegl\u0105darki, ca\u0142a sesja PunchOut \u2014 katalog produkt\u00f3w, koszyk, proces realizacji zam\u00f3wienia \u2014 pochodzi z jednego, sp\u00f3jnego \u017ar\u00f3d\u0142a: domeny PunchOut Rocket<\/strong>. Nie ma iFrame cross-origin. Nie ma plik\u00f3w cookie stron trzecich. Nag\u0142\u00f3wek frame-ancestors<\/em> jest kontrolowany przez infrastruktur\u0119 PunchOut Rocket, kt\u00f3ra ju\u017c zezwala na portale e-zam\u00f3wie\u0144. Wszystkie pliki cookie s\u0105 ustawiane i odczytywane w ramach \u017ar\u00f3d\u0142a PunchOut Rocket i s\u0105 traktowane jako pliki cookie pierwszej strony. <\/p>\n

      Przep\u0142yw sesji z w\u0142\u0105czonym odwrotnym proxy:<\/strong><\/p>\n

        \n
      • 1. Kupuj\u0105cy klika \u201ePunchOut\u201d w Ariba lub Coupa:<\/strong> System e-zam\u00f3wie\u0144 wysy\u0142a \u017c\u0105danie konfiguracji cXML lub OCI do punktu ko\u0144cowego PunchOut Rocket.<\/li>\n
      • 2. PunchOut Rocket uwierzytelnia sesj\u0119:<\/strong> Po\u015bwiadczenia s\u0105 weryfikowane, prawid\u0142owa to\u017csamo\u015b\u0107 kupuj\u0105cego jest rozwi\u0105zywana, a bezpieczny token sesji jest generowany. PunchOut Rocket loguje si\u0119 do Twojego sklepu e-commerce przy u\u017cyciu sklonowanego konta u\u017cytkownika skonfigurowanego dla tego klienta ko\u0144cowego. <\/li>\n
      • 3. Odwrotne proxy zaczyna obs\u0142ugiwa\u0107 Tw\u00f3j sklep:<\/strong> Przegl\u0105darka kupuj\u0105cego jest kierowana do adresu URL PunchOut Rocket. Wszystkie kolejne \u017c\u0105dania stron, zasob\u00f3w i wywo\u0142a\u0144 API s\u0105 przekazywane przez infrastruktur\u0119 PunchOut Rocket. Adres URL Twojego sklepu nigdy nie pojawia si\u0119 w pasku adresu przegl\u0105darki podczas sesji. <\/li>\n
      • 4. Pliki cookie, nag\u0142\u00f3wki i zasoby s\u0105 przepisywane:<\/strong> PunchOut Rocket przepisuje nag\u0142\u00f3wki odpowiedzi i domeny plik\u00f3w cookie, tak aby wszystko by\u0142o obs\u0142ugiwane w ramach jednego sp\u00f3jnego \u017ar\u00f3d\u0142a. \u017badna polityka SameSite nie ma zastosowania w r\u00f3\u017cnych \u017ar\u00f3d\u0142ach, poniewa\u017c istnieje tylko jedno \u017ar\u00f3d\u0142o. Na Twoim serwerze nie jest potrzebna bia\u0142a lista frame-ancestors, poniewa\u017c infrastruktura PunchOut Rocket obs\u0142uguje to. <\/li>\n
      • 5. Kupuj\u0105cy robi zakupy i przesy\u0142a koszyk:<\/strong> Zawarto\u015b\u0107 koszyka jest przechwytywana przez PunchOut Rocket, konwertowana do prawid\u0142owego formatu cXML lub OCI i przesy\u0142ana z powrotem do systemu zam\u00f3wie\u0144 jako prawid\u0142owo ustrukturyzowane \u017c\u0105danie zakupu.<\/li>\n<\/ul>\n

        Zero wymaganej konfiguracji serwera:<\/strong> Po w\u0142\u0105czeniu odwrotnego proxy nie musisz modyfikowa\u0107 \u017cadnych nag\u0142\u00f3wk\u00f3w HTTP, polityk plik\u00f3w cookie ani plik\u00f3w konfiguracyjnych serwera na swoim ho\u015bcie e-commerce. Infrastruktura PunchOut Rocket obs\u0142uguje ca\u0142\u0105 kompatybilno\u015b\u0107 cross-origin w Twoim imieniu. Dotyczy to niezale\u017cnie od tego, czy Twoi klienci korzystaj\u0105 z Ariba, Coupa, Jaggaer, czy jakiegokolwiek innego portalu.<\/p>\n<\/div><\/section>\n

        Zak\u0142\u00f3cenia wtyczek: Co mo\u017ce zepsu\u0107 proxy<\/strong><\/h2>\n

        Odwrotne proxy dzia\u0142a poprzez pobieranie HTML Twojego sklepu w czasie rzeczywistym i przekazywanie go do przegl\u0105darki kupuj\u0105cego. Oznacza to, \u017ce HTML generowany przez Tw\u00f3j serwer musi by\u0107 czysty i mo\u017cliwy do rozwi\u0105zania URL \u2014 ka\u017cdy tag skryptu, odwo\u0142anie do arkusza styl\u00f3w i \u017ar\u00f3d\u0142o obrazu musi u\u017cywa\u0107 standardowych \u015bcie\u017cek URL bezwzgl\u0119dnych lub wzgl\u0119dnych, kt\u00f3re PunchOut Rocket mo\u017ce poprawnie przepisa\u0107. <\/p>\n

        Pewna klasa wtyczek WordPress i WooCommerce \u0142amie to za\u0142o\u017cenie: wtyczki do minifikacji HTML i optymalizacji zasob\u00f3w<\/strong>.<\/p>\n

        Problem z kodowaniem Base64:<\/strong> Wtyczki takie jak Autoptimize<\/strong> poprawiaj\u0105 wydajno\u015b\u0107 strony poprzez \u0142\u0105czenie i minifikacj\u0119 plik\u00f3w CSS i JavaScript. Przy najbardziej agresywnych ustawieniach osadzaj\u0105 r\u00f3wnie\u017c po\u0142\u0105czon\u0105 zawarto\u015b\u0107 jako URI danych zakodowanych w Base64<\/strong> bezpo\u015brednio w HTML. Zamiast linku do arkusza styl\u00f3w, takiego jak: <link rel=”stylesheet” href=”\/wp-content\/cache\/autoptimize\/css\/autoptimize_abc123.css”><\/em>, wynik staje si\u0119 czym\u015b w rodzaju: <style>@import url(„data:text\/css;base64,Ym9keXt……”)<\/style><\/em>.<\/p>\n

        Gdy odwrotne proxy przekazuje ten HTML, te URI danych zakodowane w Base64 nie maj\u0105 adresu URL do przepisania \u2014 s\u0105 to nieprzejrzyste bloki zakodowanej zawarto\u015bci. Wszelkie zasoby, do kt\u00f3rych si\u0119 odwo\u0142uj\u0105 (obrazy t\u0142a, czcionki internetowe, dalsze importy), rozwi\u0105zuj\u0105 si\u0119 wzgl\u0119dem niew\u0142a\u015bciwego \u017ar\u00f3d\u0142a lub w og\u00f3le si\u0119 nie \u0142aduj\u0105. Rezultatem jest witryna sklepu z uszkodzonymi stylami, brakuj\u0105cymi czcionkami, niewidocznymi przyciskami i niefunkcjonalnym uk\u0142adem w iFrame zam\u00f3wie\u0144. <\/p>\n

        Wtyczki, kt\u00f3re mog\u0105 zak\u0142\u00f3ca\u0107 dzia\u0142anie:<\/strong><\/p>\n

          \n
        • Autoptimize:<\/strong> Zw\u0142aszcza gdy w\u0142\u0105czone jest \u201eInline and Defer CSS\u201d lub \u201eInline all CSS\u201d. Ca\u0142a wtyczka powinna by\u0107 wy\u0142\u0105czona podczas sesji PunchOut. <\/li>\n
        • WP Rocket:<\/strong> Opcje \u201eCombine CSS Files\u201d i \u201eCombine JavaScript Files\u201d mog\u0105 powodowa\u0107 problemy. Wy\u0142\u0105cz tylko opcje \u0142\u0105czenia\/osadzania zasob\u00f3w. <\/li>\n
        • LiteSpeed Cache:<\/strong> Minifikacja HTML i ustawienia \u0142\u0105czenia CSS\/JS powinny by\u0107 wy\u0142\u0105czone. Podstawowe buforowanie stron nie wp\u0142ywa na zachowanie proxy. <\/li>\n
        • W3 Total Cache:<\/strong> Tryb \u201eMinify\u201d dla CSS i JS mo\u017ce generowa\u0107 osadzone zasoby. Wy\u0142\u0105cz minifikacj\u0119, ale zachowaj buforowanie obiekt\u00f3w\/stron, je\u015bli jest to potrzebne. <\/li>\n
        • Standardowe wtyczki do buforowania stron:<\/strong> Wtyczki, kt\u00f3re buforuj\u0105 pe\u0142ne strony HTML bez zmiany struktury URL zasob\u00f3w, s\u0105 zazwyczaj bezpieczne.<\/li>\n<\/ul>\n

          Jak zdiagnozowa\u0107 konflikt wtyczek:<\/strong><\/p>\n

            \n
          1. Otw\u00f3rz sesj\u0119 PunchOut w przegl\u0105darce i u\u017cyj opcji Wy\u015bwietl \u017ar\u00f3d\u0142o strony<\/strong> (nie inspektora element\u00f3w DevTools, kt\u00f3ry pokazuje aktywny DOM).<\/li>\n
          2. Wyszukaj w surowym kodzie HTML ci\u0105g data:text\/css;base64,<\/em> lub data:application\/javascript;base64,<\/em>.<\/li>\n
          3. Je\u015bli znaleziono, wtyczka minifikuj\u0105ca koduje zasoby w linii. Zidentyfikuj, kt\u00f3ra wtyczka jest za to odpowiedzialna, na podstawie jej komentarzy wyj\u015bciowych w \u017ar\u00f3dle. <\/li>\n
          4. Wy\u0142\u0105cz t\u0119 wtyczk\u0119 (lub jej funkcj\u0119 kodowania w linii) i ponownie przetestuj sesj\u0119 PunchOut.<\/li>\n<\/ol>\n

            Uwaga dotycz\u0105ca wydajno\u015bci:<\/strong> Wy\u0142\u0105czenie Autoptimize lub podobnych wtyczek nie oznacza po\u015bwi\u0119cania wydajno\u015bci witryny dla zwyk\u0142ych odwiedzaj\u0105cych. Wi\u0119kszo\u015b\u0107 nowoczesnych host\u00f3w i sieci CDN zapewnia multipleksowanie HTTP\/2, kt\u00f3re sprawia, \u017ce \u0142\u0105czenie plik\u00f3w jest w du\u017cej mierze niepotrzebne.<\/p>\n<\/div><\/section>\n

            Wy\u0142\u0105czanie odwrotnego proxy: Co musisz skonfigurowa\u0107 r\u0119cznie<\/strong><\/h2>\n

            Odwrotne proxy jest domy\u015blnie w\u0142\u0105czone<\/strong> dla wszystkich witryn PunchOut Rocket i jest zdecydowanie zalecan\u0105 konfiguracj\u0105. Je\u015bli jednak odwrotne proxy zostanie wy\u0142\u0105czone w Ustawieniach zaawansowanych, kompatybilno\u015b\u0107 cross-origin staje si\u0119 Twoj\u0105 odpowiedzialno\u015bci\u0105. Ka\u017cde ograniczenie bezpiecze\u0144stwa przegl\u0105darki opisane w tym artykule b\u0119dzie mia\u0142o zastosowanie. Musisz skonfigurowa\u0107 nast\u0119puj\u0105ce elementy na w\u0142asnym serwerze lub w panelu sterowania hostingu: <\/p>\n

            1. Content-Security-Policy: frame-ancestors:<\/strong> Musisz wyra\u017anie wymieni\u0107 ka\u017cd\u0105 domen\u0119 platformy zam\u00f3wie\u0144, kt\u00f3rej u\u017cywa kt\u00f3rykolwiek z Twoich klient\u00f3w. Sk\u0142adnia konfiguracji w pliku serwera lub .htaccess powinna by\u0107 zgodna z tym wzorcem:<\/p>\n

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

            # Dodaj r\u00f3wnie\u017c X-Frame-Options dla kompatybilno\u015bci ze starszymi przegl\u0105darkami: X-Frame-Options: ALLOW-FROM https:\/\/your-client-portal.ariba.com<\/em><\/p>\n

            Zauwa\u017c, \u017ce X-Frame-Options<\/em> nie obs\u0142uguje poddomen z symbolami wieloznacznymi i zezwala tylko na jedn\u0105 warto\u015b\u0107 domeny na instancj\u0119 nag\u0142\u00f3wka. Dla klient\u00f3w na r\u00f3\u017cnych subdomenach b\u0119dziesz potrzebowa\u0107 logiki na poziomie serwera, aby dynamicznie ustawia\u0107 nag\u0142\u00f3wek na podstawie nag\u0142\u00f3wka \u017c\u0105dania Referer<\/em> lub Origin<\/em>. <\/p>\n

            2. Atrybuty plik\u00f3w cookie SameSite:<\/strong> Wszystkie pliki cookie sesji i uwierzytelniania musz\u0105 zosta\u0107 zaktualizowane, aby zawiera\u0142y SameSite=None; Secure<\/em>. W przypadku stosu WordPress\/WooCommerce dzia\u0142aj\u0105cego na PHP, najbardziej niezawodnym podej\u015bciem jest ustawienie tego globalnie na poziomie PHP: <\/p>\n

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

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

            Sprawd\u017a, czy wszystkie wtyczki stron trzecich (bramki p\u0142atno\u015bci, analityka, mened\u017cery sesji) r\u00f3wnie\u017c u\u017cywaj\u0105 SameSite=None; Secure<\/em> dla swoich plik\u00f3w cookie. Pojedynczy niezgodny plik cookie z wtyczki mo\u017ce przerwa\u0107 sesj\u0119, nawet je\u015bli Twoje podstawowe pliki cookie platformy s\u0105 poprawnie skonfigurowane. <\/p>\n

            Ci\u0105g\u0142e obci\u0105\u017cenie konserwacyjne:<\/strong> Ka\u017cdy nowy klient na nowej platformie zam\u00f3wie\u0144 dodaje kolejn\u0105 domen\u0119 do Twojej bia\u0142ej listy frame-ancestors<\/em>. Migracje platform zam\u00f3wie\u0144, nowe wzorce subdomen i aktualizacje zabezpiecze\u0144 przegl\u0105darek mog\u0105 po cichu przerywa\u0107 istniej\u0105ce sesje bez ostrze\u017cenia. To obci\u0105\u017cenie konserwacyjne jest g\u0142\u00f3wnym powodem, dla kt\u00f3rego PunchOut Rocket domy\u015blnie w\u0142\u0105cza odwrotne proxy.<\/p>\n<\/div><\/section>\n

            W skr\u00f3cie: Odwrotne proxy w\u0142\u0105czone vs. wy\u0142\u0105czone<\/strong><\/h2>\n
              \n
            • frame-ancestors \/ X-Frame-Options:<\/strong> Obs\u0142ugiwane przez PunchOut Rocket (Proxy w\u0142\u0105czone) vs. Konfiguruj na swoim serwerze (Proxy wy\u0142\u0105czone).<\/li>\n
            • Pliki cookie SameSite=None; Secure:<\/strong> Brak plik\u00f3w cookie cross-origin (Proxy w\u0142\u0105czone) vs. Musz\u0105 by\u0107 ustawione dla wszystkich plik\u00f3w cookie (Proxy wy\u0142\u0105czone).<\/li>\n
            • Nowy klient na nowej platformie:<\/strong> Zero zmian w konfiguracji (Proxy w\u0142\u0105czone) vs. Dodaj now\u0105 domen\u0119 do bia\u0142ej listy (Proxy wy\u0142\u0105czone).<\/li>\n
            • Autoptimize \/ wtyczki do osadzania zasob\u00f3w:<\/strong> Musz\u0105 by\u0107 wy\u0142\u0105czone (Proxy w\u0142\u0105czone) vs. Brak proxy do zak\u0142\u00f3cania (Proxy wy\u0142\u0105czone).<\/li>\n
            • Wymaganie HTTPS:<\/strong> Wymuszane przez PunchOut Rocket (Proxy w\u0142\u0105czone) vs. Wymagane przez SameSite=None (Proxy wy\u0142\u0105czone).<\/li>\n
            • Wymagany dost\u0119p do serwera:<\/strong> Brak (Proxy w\u0142\u0105czone) vs. Wymagany do konfiguracji nag\u0142\u00f3wk\u00f3w (Proxy wy\u0142\u0105czone).<\/li>\n
            • Konserwacja w czasie:<\/strong> Zero (Proxy w\u0142\u0105czone) vs. Ci\u0105g\u0142a dla ka\u017cdego nowego klienta (Proxy wy\u0142\u0105czone).<\/li>\n<\/ul>\n<\/div><\/section>\n

              Podsumowanie<\/strong><\/h2>\n

              Niewidzialna \u015bciana mi\u0119dzy Twoim sklepem e-commerce a portalem zam\u00f3wie\u0144 kupuj\u0105cego nie jest b\u0142\u0119dem w Twoim kodzie ani w systemie Twojego klienta. Jest to przewidywalna konsekwencja sposobu, w jaki modele bezpiecze\u0144stwa przegl\u0105darek obs\u0142uguj\u0105 osadzanie iFrame cross-origin \u2014 i dotyczy ka\u017cdego<\/em> dostawcy, kt\u00f3ry pr\u00f3buje po\u0142\u0105czy\u0107 si\u0119 z Ariba, Coupa lub Jaggaer za pomoc\u0105 gotowej witryny e-commerce. <\/p>\n

              Polityka bezpiecze\u0144stwa tre\u015bci frame-ancestors<\/em> i ograniczenie plik\u00f3w cookie SameSite<\/em> istniej\u0105 z dobrych powod\u00f3w: chroni\u0105 u\u017cytkownik\u00f3w przed clickjackingiem i \u015bledzeniem mi\u0119dzy witrynami. Ale tworz\u0105 one prawdziw\u0105 niekompatybilno\u015b\u0107 z modelem PunchOut, kt\u00f3ra wymaga rozwi\u0105zania strukturalnego, a nie poprawki konfiguracyjnej. <\/p>\n

              Odwrotne proxy PunchOut Rocket zapewnia to rozwi\u0105zanie strukturalne. Kieruj\u0105c ca\u0142\u0105 sesj\u0119 kupuj\u0105cego przez infrastruktur\u0119 PunchOut Rocket, przegl\u0105darka widzi jedno, sp\u00f3jne \u017ar\u00f3d\u0142o przez ca\u0142\u0105 sesj\u0119. Ograniczenia iFrame cross-origin po prostu nie maj\u0105 zastosowania. Pliki cookie s\u0105 plikami pierwszej strony. Nie s\u0105 wymagane \u017cadne zmiany konfiguracji serwera w Twoim sklepie i nie jest wymagana ci\u0105g\u0142a konserwacja, gdy wdra\u017casz nowych klient\u00f3w na nowych platformach zam\u00f3wie\u0144. <\/p>\n

              Jedynym kompromisem jest kompatybilno\u015b\u0107 wtyczek: je\u015bli Tw\u00f3j stos WordPress lub WooCommerce u\u017cywa agresywnych narz\u0119dzi do minifikacji HTML, takich jak Autoptimize z w\u0142\u0105czonym kodowaniem inline Base64, musz\u0105 one zosta\u0107 wy\u0142\u0105czone. W praktyce ma to znikomy wp\u0142yw na regularn\u0105 wydajno\u015b\u0107 witryny i jest jednorazow\u0105 zmian\u0105 konfiguracji. <\/p>\n

              Dla dostawc\u00f3w, kt\u00f3rzy potrzebuj\u0105 pe\u0142nej kontroli nad \u015brodowiskiem serwerowym i wol\u0105 samodzielnie obs\u0142ugiwa\u0107 konfiguracj\u0119 cross-origin, proxy mo\u017cna wy\u0142\u0105czy\u0107 \u2014 ale wymagania r\u0119czne s\u0105 znaczne i rosn\u0105 z ka\u017cd\u0105 now\u0105 relacj\u0105 z klientem. Dla zdecydowanej wi\u0119kszo\u015bci dostawc\u00f3w odwrotne proxy jest w\u0142a\u015bciwym domy\u015blnym rozwi\u0105zaniem: bezproblemowa, bezobs\u0142ugowa kompatybilno\u015b\u0107 z ka\u017cdym portalem e-zam\u00f3wie\u0144, z kt\u00f3rego korzystaj\u0105 Twoi klienci.<\/p>\n<\/div><\/section>\n<\/div><\/div><\/main><\/div><\/div>