Ang iyong Magento redirect loop ay malamang hindi ang VPN

Nakikita mo ang 302 sa access log, hindi naglo-load ang tindahan sa pamamagitan ng VPN, at ang konklusyon ay nagsusulat mismo. Ang konklusyong iyon ay karaniwang mali sa kawili-wiling paraan. Ang tugon ng redirect ay nagtatala ng destinasyong sinabihan sa browser na puntahan, at wala itong sinasabi tungkol sa kung ang tunnel, certificate o application ang gumawa ng problema. Ang linya sa log ay simula ng pagsisiyasat, hindi ang natuklasan nito.

Sinasabi ng 302 kung saan, hindi kung bakit

Ang entry sa access log ay nagtatala ng request, status at laki, at karaniwang inaalis ang Location header na mahalaga. Ang isang redirect ay maaaring maging ganap na normal: isang canonical hostname, isang normalisasyon ng trailing slash, isang paglipat sa HTTPS. Ang kailangan mo ay ang pagkakasunod-sunod, dahil ang isang pagtalon at isang loop ay magkaibang mga sira na may magkaibang may-ari. Ang paulit-ulit na pagtalon sa pagitan ng mga scheme ay tumuturo sa paghawak ng URL at scheme. Ang pagtalon sa isang pangalang hindi kayang lutasin ng browser ay tumuturo sa ibang lugar nang husto.

Wala sa mga iyon ang ebidensya tungkol sa VPN. Ang tunnel ay isang landas; ang redirect ay isang utos na isinulat ng application.

Hulihin ang chain, hindi ang linya sa log

Gamitin ang network view ng browser at itala ang apat na field sa bawat pagtalon: ang hiniling na URL, status, Location header at oras. Tapusin sa huling tugon o sa error ng koneksyon, dahil ang kawili-wiling kaso ay ang pagtalon na hindi kailanman natapos. Gawin ito isang beses sa landas na gumagana at isang beses sa nabibigo, sa parehong account at parehong nabigasyon. Ang paghahambing ng dalawang chain ay mas mahalaga kaysa sa anumang solong linya sa log.

Panatilihing pribado ang rekord na iyon. Ang mga URL ay may dalang session identifier, at ang naka-save na browser archive ay may dalang higit sa inaasahan mo. Alisin ang mga query string bago i-paste ang anuman sa isang ticket.

Ang ideya ng application tungkol sa sarili nitong URL

Ang Magento ay bumubuo ng mga absolute URL mula sa configuration, na may saklaw sa bawat website o store view. Ang bin/magento config:show web/secure/base_url ay nagpi-print ng halagang pinaniniwalaan ng application, at madalas iyon ay isang hostname na natira mula sa isang build o migration kaysa sa ginamit ng browser. Kung may panloob na host na nakasaad doon, ang browser ay ipinapadala sa lugar na hindi niya maabot, at walang pagbabago sa tunnel ang makakapag-ayos nito.

Ihambing ang secure at insecure na base URL sa mga pampublikong pangalan sa harap mo. Ang isang hindi pagkakatugma sa alinman sa dalawa ay gumagawa ng eksaktong redirect na tinitingnan mo.

Ang mga header ng pinagkakatiwalaang proxy ay isang kontrata

Kapag nagtatapos ang TLS sa isang load balancer, nakikita ng application ang simpleng HTTP at kailangang sabihan ng kabaligtaran. Pinangalanan ng setting ng offloader header ang header na itinatakda ng proxy, tulad ng forwarded protocol, at pinagkakatiwalaan ito ng application sa mga desisyon sa scheme.

Ang pagtitiwalang iyon ay isang kontrata sa isang proxy, hindi isang pangkalahatang pahintulot. Ang pagtanggap ng header mula sa mga arbitraryong kliyente ay nagpapahintulot sa sinuman na mag-angkin ng scheme, kaya nararapat lamang ito kung saan itinatakda ito ng itinalagang proxy. Kung hindi magkasundo ang pangalan ng header at ang pag-uugali ng proxy, gumagawa ang application ng mga redirect sa scheme na hindi kailanman ginamit ng browser, at nagsasara ang loop. Suriin nang sabay ang configuration ng proxy at ang setting ng application, pagkatapos ay i-flush ang configuration cache para magkabisa ang pagbabago.

Kapag ang loop ay isang session, hindi isang ruta

Ang chain na laging bumabalik sa pag-sign in ay karaniwang problema sa cookie. Suriin kung ang session cookie ay inisyu para sa hostname na aktwal na ginamit ng browser, at kung namarkahan itong secure sa isang koneksyong itinuturing na secure ng browser. Ang cookie na naka-scope sa maling domain ay gumagawa ng login loop na eksaktong kamukha ng pagkabigo sa routing.

Ayusin ang napatunayang hindi pagkakatugma sa may-ari nito, maging ang base URL, domain ng cookie o kontrata sa proxy, pagkatapos ay subukan muli ang buong nabigasyon sa halip na panoorin ang isang 302 na nawawala. Ang pag-disable ng mga kinakailangan sa HTTPS upang basagin ang loop ay nagpapalit ng redirect sa mas masamang problema. Kapag tapos na ang pagbabago, suriin nang hiwalay ang tunnel: humiling ng kilalang pribadong resource at kumpirmahing dumarating ito, upang ang susunod na redirect ay may malinis na baseline na maihahambing.