Vaša Magento petlja preusmeravanja verovatno nije VPN

Vidite 302 u dnevniku pristupa, prodavnica se ne učitava kroz VPN i zaključak se sam nameće. Taj zaključak je obično pogrešan na zanimljiv način. Odgovor preusmeravanja beleži odredište na koje je pregledaču rečeno da ode i ne govori ništa o tome da li je problem stvorio tunel, sertifikat ili aplikacija. Red u dnevniku je početak istrage, a ne njen nalaz.

302 kaže kuda, a ne zašto

Zapis u dnevniku pristupa beleži zahtev, status i veličinu i obično izostavlja zaglavlje Location koje je važno. Jedno preusmeravanje može biti sasvim normalno: kanonsko ime hosta, normalizacija završne kose crte, prelazak na HTTPS. Potreban vam je sled, jer su jedan skok i petlja različite greške sa različitim vlasnicima. Ponovljeni skokovi između šema upućuju na obradu URL-a i šeme. A skok na ime koje pregledač ne može da razreši upućuje negde sasvim drugde.

Ništa od toga nije dokaz o VPN-u. Tunel je put; preusmeravanje je uputstvo koje je napisala aplikacija.

Zabeležite lanac, a ne red iz dnevnika

Koristite mrežni prikaz pregledača i zabeležite četiri polja po skoku: traženi URL, status, zaglavlje Location i vreme. Završite ili konačnim odgovorom ili greškom veze, jer je zanimljiv slučaj skok koji se nikada ne dovrši. Uradite to jednom na putu koji radi i jednom na onom koji ne uspeva, sa istim nalogom i istom navigacijom. Poređenje dva lanca vredi više od ijednog pojedinačnog reda u dnevniku.

Držite taj zapis privatnim. URL-ovi nose identifikatore sesije, a sačuvana arhiva pregledača nosi više nego što očekujete. Uklonite nizove upita pre nego što bilo šta zalepite u tiket.

Predstava aplikacije o sopstvenom URL-u

Magento generiše apsolutne URL-ove iz konfiguracije, sa dometom po veb-lokaciji ili prikazu prodavnice. bin/magento config:show web/secure/base_url ispisuje vrednost u koju aplikacija veruje, a to je često ime hosta zaostalo od izgradnje ili migracije umesto onog koje je pregledač koristio. Ako tamo stoji interno ime hosta, pregledač se šalje negde kuda ne može da stigne i nikakva promena tunela to ne ispravlja.

Uporedite bezbedni i nebezbedni osnovni URL sa javnim imenima pred sobom. Neusklađenost u bilo kojem od njih proizvodi upravo preusmeravanje u koje gledate.

Zaglavlja pouzdanog proksija su ugovor

Kada TLS završava na balanseru opterećenja, aplikacija vidi običan HTTP i mora joj se reći drugačije. Postavka zaglavlja offloadera imenuje zaglavlje koje proksije postavlja, poput prosleđenog protokola, i aplikacija mu veruje pri odlukama o šemi.

To poverenje je ugovor sa jednim proksijem, a ne opšta dozvola. Prihvatanje zaglavlja od proizvoljnih klijenata dopušta svakome da tvrdi šemu, zato ono pripada samo tamo gde ga postavlja određeni proksije. Ako se ime zaglavlja i ponašanje proksija ne slažu, aplikacija generiše preusmeravanja na šemu koju pregledač nikada nije koristio i petlja se zatvara. Proverite konfiguraciju proksija i postavku aplikacije zajedno, zatim ispraznite keš konfiguracije da promena stupi na snagu.

Kada je petlja sesija, a ne ruta

Lanac koji se uvek vraća na prijavu obično je problem sa kolačićem. Proverite da li je kolačić sesije izdat za ime hosta koje je pregledač stvarno koristio i da li je označen kao bezbedan na vezi koju pregledač smatra bezbednom. Kolačić vezan za pogrešan domen stvara petlju prijave koja izgleda upravo kao kvar usmeravanja.

Ispravite dokazanu neusklađenost kod njenog vlasnika, bilo da je to osnovni URL, domen kolačića ili ugovor sa proksijem, pa ponovo testirajte celu navigaciju umesto da gledate kako jedan 302 nestaje. Isključivanje HTTPS zahteva radi prekidanja petlje menja preusmeravanje za gorljiv problem. Kada je promena gotova, proverite tunel odvojeno: zatražite poznati privatni resurs i potvrdite da stiže, kako bi sledeće preusmeravanje imalo čistu osnovu za poređenje.