Váš cyklus presmerovaní v Magente pravdepodobne nie je kvôli VPN

V prístupovom logu vidíte 302, výklad sa nenačíta cez VPN a záver sa napíše sám. Ten záver býva zaujímavo nesprávny. Odpoveď s presmerovaním zaznamenáva cieľ, kam mal prehliadač ísť, a nič nehovorí o tom, či problém spôsobil tunel, certifikát alebo aplikácia. Riadok v logu je začiatok vyšetrovania, nie jeho zistenie.

302 hovorí kam, nie prečo

Záznam v prístupovom logu zachytáva požiadavku, stav a veľkosť a zvyčajne vynecháva hlavičku Location, na ktorej záleží. Jedno presmerovanie môže byť úplne normálne: kanonické meno hostiteľa, normalizácia koncovej lomky, prechod na HTTPS. Potrebujete postupnosť, pretože jeden skok a slučka sú rôzne poruchy s rôznymi vlastníkmi. Opakované skoky medzi schémami ukazujú na spracovanie URL a schémy. Skok na meno, ktoré prehliadač nevie vyriešiť, ukazuje úplne inam.

Nič z toho nie je dôkaz o VPN. Tunel je cesta; presmerovanie je pokyn, ktorý napísala aplikácia.

Zachyťte reťazec, nie riadok logu

Použite sieťové zobrazenie prehliadača a pri každom skoku si poznačte štyri polia: požadovanú URL, stav, hlavičku Location a čas. Skončite buď konečnou odpoveďou, alebo chybou pripojenia, pretože zaujímavý je prípad skoku, ktorý sa nikdy nedokončí. Urobte to raz na funkčnej ceste a raz na tej, ktorá zlyháva, s rovnakým účtom a rovnakou navigáciou. Porovnanie dvoch reťazcov má väčšiu cenu než ktorýkoľvek jednotlivý riadok v logu.

Ten záznam uchovávajte v súkromí. URL nesú identifikátory relácie a uložený archív prehliadača nesie viac, než čakáte. Pred vložením čohokoľvek do tiketu odstráňte dopytové reťazce.

Predstava aplikácie o jej vlastnej URL

Magento generuje absolútne URL z konfigurácie, s rozsahom na web alebo zobrazenie obchodu. bin/magento config:show web/secure/base_url vypíše hodnotu, ktorej aplikácia verí, a tou je často meno hostiteľa zostávajúce po builde alebo migrácii namiesto toho, ktoré použil prehliadač. Ak uvádza interného hostiteľa, prehliadač je posielaný niekam, kam sa nedostane, a žiadna zmena tunela to nespraví.

Porovnajte zabezpečenú a nezabezpečenú základnú URL s verejnými menami pred sebou. Nezhoda v ktorejkoľvek z nich vytvára presne to presmerovanie, na ktoré sa pozeráte.

Hlavičky dôveryhodnej proxy sú zmluva

Keď TLS končí na vyvažovači záťaže, aplikácia vidí obyčajný HTTP a musí sa jej povedať inak. Nastavenie hlavičky offloadera pomenúva hlavičku, ktorú proxy nastavuje, napríklad preposlaný protokol, a aplikácia jej pri rozhodovaní o schéme dôveruje.

Tá dôvera je zmluva s jednou proxy, nie všeobecné povolenie. Prijímanie hlavičky od ľubovoľných klientov umožňuje komukoľvek tvrdiť schému, a preto patrí len tam, kde ju nastavuje určená proxy. Ak sa názov hlavičky a správanie proxy nezhodujú, aplikácia generuje presmerovania na schému, ktorú prehliadač nikdy nepoužil, a slučka sa uzavrie. Skontrolujte konfiguráciu proxy a nastavenie aplikácie spoločne, potom vyprázdnite medzipamäť konfigurácie, aby sa zmena prejavila.

Keď je slučka relácia, nie trasa

Reťazec, ktorý sa vždy vracia k prihláseniu, býva problém s cookie. Skontrolujte, či bola relačná cookie vydaná pre meno hostiteľa, ktoré prehliadač skutočne použil, a či bola označená ako zabezpečená na spojení, ktoré prehliadač považuje za zabezpečené. Cookie viazaná na nesprávnu doménu vytvára prihlasovaciu slučku, ktorá vyzerá presne ako zlyhanie smerovania.

Opravte preukázanú nezhodu u jej vlastníka, či už je to základná URL, doména cookie alebo zmluva s proxy, a potom znova otestujte celú navigáciu, namiesto toho aby ste sledovali, ako jeden 302 mizne. Vypnutie požiadaviek HTTPS na prelomenie slučky mení presmerovanie za horší problém. Keď je zmena hotová, skontrolujte tunel oddelene: vyžiadajte známy súkromný zdroj a potvrďte, že dorazí, aby ďalšie presmerovanie malo čistú základnú líniu na porovnanie.