Magento-uudelleenohjaussilmukkasi ei todennäköisesti johdu VPN:stä

Näet lokissa 302:n, kauppa ei lataudu VPN:n kautta ja johtopäätös kirjoittaa itsensä. Se johtopäätös on yleensä mielenkiintoisella tavalla väärä. Uudelleenohjausvastaus tallentaa kohteen, johon selaimen käskettiin mennä, eikä kerro mitään siitä, aiheuttiko ongelman tunneli, varmenne vai sovellus. Lokirivi on tutkinnan alku, ei sen tulos.

302 kertoo minne, ei miksi

Käyttölokin merkintä tallentaa pyynnön, tilan ja koon ja jättää yleensä pois sen Location-otsikon, jolla on merkitystä. Yksi uudelleenohjaus voi olla täysin normaali: kanoninen isäntänimi, loppukauttaviivan normalisointi, siirtyminen HTTPS:ään. Tarvitset järjestyksen, koska yksittäinen hyppy ja silmukka ovat eri vikoja eri omistajineen. Toistuvat hypyt skeemojen välillä viittaavat URL:n ja skeeman käsittelyyn. Hyppy nimeen, jota selain ei pysty ratkaisemaan, viittaa aivan muualle.

Mikään tuosta ei ole todiste VPN:stä. Tunneli on polku; uudelleenohjaus on ohje, jonka sovellus kirjoitti.

Tallenna ketju, älä lokiriviä

Käytä selaimen verkkonäkymää ja kirjaa neljä kenttää joka hypyltä: pyydetty URL, tila, Location-otsikko ja aika. Lopeta joko lopulliseen vastaukseen tai yhteysvirheeseen, koska kiinnostava tapaus on hyppy, joka ei koskaan valmistu. Tee se kerran toimivalla polulla ja kerran epäonnistuvalla, samalla tilillä ja samalla navigoinnilla. Kahden ketjun vertailu on arvokkaampaa kuin yksikään lokin rivi.

Pidä tuo tallenne yksityisenä. URL:t kuljettavat istunnon tunnisteita, ja tallennettu selainarkisto kuljettaa enemmän kuin odotat. Poista kyselymerkkijonot ennen kuin liität mitään tikettiin.

Sovelluksen käsitys omasta URL-osoitteestaan

Magento luo absoluuttiset URL:t kokoonpanosta, rajattuna verkkosivuston tai kauppanäkymän mukaan. bin/magento config:show web/secure/base_url tulostaa arvon, johon sovellus uskoo, ja se on usein rakennuksesta tai siirrosta jäänyt isäntänimi sen sijaan, että se olisi se, jota selain käytti. Jos siinä nimetään sisäinen isäntä, selain lähetetään paikkaan, johon se ei pääse, eikä mikään tunnelin muutos korjaa sitä.

Vertaa suojattua ja suojaamatonta perus-URL:ää edessäsi oleviin julkisiin nimiin. Epäjohdonmukaisuus kummassa tahansa tuottaa juuri sen uudelleenohjauksen, jota tuijotat.

Luotetun välityspalvelimen otsikot ovat sopimus

Kun TLS päättyy kuormantasaajaan, sovellus näkee pelkän HTTP:n ja sille on kerrottava toisin. Offloader-otsikon asetus nimeää otsikon, jonka välityspalvelin asettaa, kuten välitetyn protokollan, ja sovellus luottaa siihen skeemapäätöksissä.

Tuo luottamus on sopimus yhden välityspalvelimen kanssa, ei yleinen lupa. Otsikon hyväksyminen mielivaltaisilta asiakkailta antaa kenen tahansa väittää skeemaa, minkä vuoksi se kuuluu vain sinne, missä nimetty välityspalvelin asettaa sen. Jos otsikon nimi ja välityspalvelimen käyttäytyminen eivät vastaa toisiaan, sovellus luo uudelleenohjauksia skeemaan, jota selain ei koskaan käyttänyt, ja silmukka sulkeutuu. Tarkista välityspalvelimen kokoonpano ja sovelluksen asetus yhdessä ja tyhjennä sitten kokoonpanovälimuisti, jotta muutos tulee voimaan.

Kun silmukka on istunto, ei reitti

Ketju, joka palaa aina kirjautumiseen, on yleensä evästeongelma. Tarkista, myönnettiinkö istuntoeväste sille isäntänimelle, jota selain todella käytti, ja merkittiinkö se turvalliseksi yhteydellä, jota selain pitää turvallisena. Väärään verkkotunnukseen rajattu eväste tuottaa kirjautumissilmukan, joka näyttää täsmälleen reititysvialta.

Korjaa osoitettu epäjohdonmukaisuus sen omistajassa, olipa se perus-URL, evästeen verkkotunnus tai välityspalvelinsopimus, ja testaa sitten koko navigointi uudelleen sen sijaan, että katselet yhden 302:n katoamista. HTTPS-vaatimusten poistaminen silmukan katkaisemiseksi vaihtaa uudelleenohjauksen pahempaan ongelmaan. Kun muutos on tehty, tarkista tunneli erikseen: pyydä tunnettua yksityistä resurssia ja varmista, että se saapuu, jotta seuraavalla uudelleenohjauksella on puhdas vertailupohja.