Vaša Magento petlja preusmjeravanja vjerojatno nije VPN

Vidite 302 u dnevniku pristupa, trgovina se ne učitava kroz VPN i zaključak se sam nameće. Taj zaključak obično je na zanimljiv način pogrešan. Odgovor preusmjeravanja bilježi odredište na koje je pregledniku rečeno da ode i ne govori ništa o tome je li problem stvorio tunel, certifikat ili aplikacija. Redak u dnevniku početak je istrage, a ne njezin nalaz.

302 govori kamo, a ne zašto

Zapis u dnevniku pristupa bilježi zahtjev, status i veličinu te obično izostavlja zaglavlje Location koje je važno. Jedno preusmjeravanje može biti posve normalno: kanonsko ime hosta, normalizacija završne kose crte, prijelaz na HTTPS. Potreban vam je slijed, jer su jedan skok i petlja različite greške s različitim vlasnicima. Ponovljeni skokovi između shema upućuju na obradu URL-a i sheme. A skok na ime koje preglednik ne može razriješiti upućuje negdje posve drugamo.

Ništa od toga nije dokaz o VPN-u. Tunel je put; preusmjeravanje je uputa koju je napisala aplikacija.

Zabilježite lanac, a ne redak dnevnika

Poslužite se mrežnim prikazom preglednika i zabilježite četiri polja po skoku: traženi URL, status, zaglavlje Location i vrijeme. Završite ili konačnim odgovorom ili pogreškom veze, jer je zanimljiv slučaj skok koji se nikada ne dovrši. Učinite to jednom na radnom putu i jednom na neispravnom, s istim računom i istom navigacijom. Usporedba dvaju lanaca vrijedi više od ijednog retka u dnevniku.

Taj zapis držite privatnim. URL-ovi nose identifikatore sesije, a spremljena arhiva preglednika nosi više nego što očekujete. Uklonite nizove upita prije nego što išta zalijepite u tiket.

Predodžba aplikacije o vlastitom URL-u

Magento generira apsolutne URL-ove iz konfiguracije, s dosegom po web-lokaciji ili prikazu trgovine. bin/magento config:show web/secure/base_url ispisuje vrijednost u koju aplikacija vjeruje, a to je često ime hosta zaostalo od izgradnje ili migracije umjesto onoga koje je preglednik rabio. Ako ondje stoji interno ime hosta, preglednik se šalje negdje kamo ne može doći i nikakva promjena tunela to ne ispravlja.

Usporedite sigurni i nesigurni osnovni URL s javnim imenima pred sobom. Neusklađenost u bilo kojem od njih proizvodi upravo preusmjeravanje koje gledate.

Zaglavlja pouzdanog proxyja su ugovor

Kad TLS završava na balanseru opterećenja, aplikacija vidi običan HTTP i mora joj se reći drukčije. Postavka zaglavlja offloadera imenuje zaglavlje koje proxy postavlja, poput proslijeđenog protokola, i aplikacija mu vjeruje pri odlukama o shemi.

To je povjerenje ugovor s jednim proxyjem, a ne opće dopuštenje. Prihvaćanje zaglavlja od proizvoljnih klijenata dopušta svakome da tvrdi shemu, zato ono pripada samo ondje gdje ga postavlja određeni proxy. Ako se ime zaglavlja i ponašanje proxyja ne slažu, aplikacija generira preusmjeravanja na shemu koju preglednik nikada nije rabio i petlja se zatvara. Provjerite konfiguraciju proxyja i postavku aplikacije zajedno, zatim ispraznite predmemoriju konfiguracije da promjena stupi na snagu.

Kad je petlja sesija, a ne ruta

Lanac koji se uvijek vraća na prijavu obično je problem s kolačićem. Provjerite je li kolačić sesije izdan za ime hosta koje je preglednik stvarno rabio i je li označen kao siguran na vezi koju preglednik smatra sigurnom. Kolačić vezan uz pogrešnu domenu stvara petlju prijave koja izgleda upravo kao kvar usmjeravanja.

Ispravite dokazanu neusklađenost kod njezina vlasnika, bila to osnovni URL, domena kolačića ili ugovor s proxyjem, pa ponovno testirajte cijelu navigaciju umjesto da gledate kako jedan 302 nestaje. Isključivanje HTTPS zahtjeva radi prekidanja petlje mijenja preusmjeravanje za gorljiv problem. Kad je promjena gotova, provjerite tunel odvojeno: zatražite poznati privatni resurs i potvrdite da stiže, kako bi sljedeće preusmjeravanje imalo čistu osnovu za usporedbu.