Váš cyklus přesměrování v Magentu pravděpodobně není kvůli VPN

V přístupovém logu vidíte 302, výloha se přes VPN nenačte a závěr se napíše sám. Ten závěr je obvykle zajímavě špatný. Odpověď s přesměrováním zaznamenává cíl, kam měl prohlížeč jít, a nic neříká o tom, zda problém způsobil tunel, certifikát nebo aplikace. Řádek v logu je začátek vyšetřování, ne jeho zjištění.

302 říká kam, ne proč

Záznam v přístupovém logu zachycuje požadavek, stav a velikost a obvykle vynechává hlavičku Location, na které záleží. Jedno přesměrování může být zcela normální: kanonické jméno hostitele, normalizace koncového lomítka, přechod na HTTPS. Potřebujete posloupnost, protože jeden skok a smyčka jsou různé závady s různými vlastníky. Opakované skoky mezi schématy ukazují na zpracování URL a schématu. Skok na jméno, které prohlížeč neumí přeložit, ukazuje úplně jinam.

Nic z toho není důkaz o VPN. Tunel je cesta; přesměrování je pokyn, který napsala aplikace.

Zachyťte řetězec, ne řádek logu

Použijte síťové zobrazení prohlížeče a u každého skoku si poznamenejte čtyři pole: požadovanou URL, stav, hlavičku Location a čas. Skončete buď konečnou odpovědí, nebo chybou připojení, protože zajímavý je případ skoku, který se nikdy nedokončí. Udělejte to jednou na funkční cestě a jednou na selhávající, se stejným účtem a stejnou navigací. Porovnání dvou řetězců má větší cenu než kterýkoli jednotlivý řádek v logu.

Ten záznam udržujte v soukromí. URL nesou identifikátory relace a uložený archiv prohlížeče nese víc, než čekáte. Před vložením čehokoli do tiketu odstraňte dotazovací řetězce.

Představa aplikace o její vlastní URL

Magento generuje absolutní URL z konfigurace, s rozsahem na web nebo zobrazení obchodu. bin/magento config:show web/secure/base_url vypíše hodnotu, které aplikace věří, a tou je často jméno hostitele zbylé z buildu nebo migrace místo toho, které použil prohlížeč. Pokud uvádí interního hostitele, je prohlížeč posílán někam, kam se nedostane, a žádná změna tunelu to nespraví.

Porovnejte zabezpečenou a nezabezpečenou základní URL s veřejnými jmény před sebou. Neshoda v kterékoli z nich vytváří právě to přesměrování, na které se díváte.

Hlavičky důvěryhodné proxy jsou smlouva

Když TLS končí na vyrovnávacím zařízení zátěže, aplikace vidí prostý HTTP a musí se jí říct jinak. Nastavení hlavičky offloaderu pojmenovává hlavičku, kterou proxy nastavuje, například přeposlaný protokol, a aplikace jí při rozhodování o schématu věří.

Tato důvěra je smlouva s jedním proxy, ne obecné povolení. Přijímání hlavičky od libovolných klientů umožňuje komukoli tvrdit schéma, a proto patří jen tam, kde ji nastavuje určený proxy. Pokud se název hlavičky a chování proxy neshodují, aplikace generuje přesměrování na schéma, které prohlížeč nikdy nepoužil, a smyčka se uzavře. Zkontrolujte konfiguraci proxy a nastavení aplikace společně, poté vyprázdněte mezipaměť konfigurace, aby se změna projevila.

Když je smyčka relace, ne trasa

Řetězec, který se vždy vrací k přihlášení, bývá problém s cookie. Zkontrolujte, zda byla relační cookie vydána pro jméno hostitele, které prohlížeč skutečně použil, a zda byla označena jako zabezpečená na spojení, které prohlížeč považuje za zabezpečené. Cookie vázaná na špatnou doménu vytváří přihlašovací smyčku, která vypadá přesně jako selhání směrování.

Opravte prokázanou neshodu u jejího vlastníka, ať už je to základní URL, doména cookie nebo smlouva s proxy, a pak znovu otestujte celou navigaci, místo abyste sledovali, jak jeden 302 mizí. Vypnutí požadavků HTTPS kvůli prolomení smyčky mění přesměrování za horší problém. Když je změna hotová, zkontrolujte tunel zvlášť: vyžádejte známý soukromý zdroj a potvrďte, že dorazí, aby další přesměrování mělo čistou základnu pro srovnání.