Magento-omdirigeringsløkka di er truleg ikkje VPN-en

Du ser 302 i tilgangsloggen, butikken lastar ikkje gjennom VPN-en, og konklusjonen skriv seg sjølv. Den konklusjonen er vanlegvis feil på ein interessant måte. Eit omdirigeringssvar registrerer ein destinasjon som nettlesaren vart beden om å besøkje, og det seier ingenting om tunnelen, sertifikatet eller applikasjonen skapte problemet. Logglinja er starten på granskinga, ikkje funnet.

Ein 302 seier kvar, ikkje kvifor

Ei oppføring i tilgangsloggen registrerer førespurnaden, statusen og storleiken, og utelèt vanlegvis Location-overskrifta som betyr noko. Éin einaste omdirigering kan vere heilt normal: eit kanonisk vertsnamn, ei normalisering av den avsluttande skråstreken, eit byte til HTTPS. Det du treng er rekkjefølgja, fordi eit hopp og ei løkke er ulike feil med ulike eigarar. Gjentekne hopp mellom skjema peikar på handsaming av URL og skjema. Eit hopp til eit namn nettlesaren ikkje kan slå opp, peikar ein heilt annan stad.

Ingen av desse er prov om VPN-en. Tunnelen er ein veg; omdirigeringa er ein instruks applikasjonen skreiv.

Fang kjeda, ikkje logglinja

Bruk nettverksvisinga i nettlesaren og noter fire felt per hopp: den førespurde URL-en, statusen, Location-overskrifta og tida. Avslutt med anten det endelege svaret eller tilkoplingsfeilen, fordi det interessante tilfellet er hoppet som aldri vert fullført. Gjer dette éin gong på ein veg som fungerer og éin gong på den som feilar, med same konto og same navigasjon. Å samanlikne to kjeder er verdt meir enn noka einskild linje i ein logg.

Hald den registreringa privat. URL-ar ber sesjonsidentifikatorar, og eit lagra nettlesararkiv ber meir enn du ventar. Fjern spørjestrengar før du limer noko inn i ei sak.

Oppfatninga applikasjonen har av sin eigen URL

Magento genererer absolutte URL-ar frå konfigurasjonen, avgrensa per nettstad eller butikkvising. bin/magento config:show web/secure/base_url skriv ut verdien applikasjonen trur på, og den er ofte eit vertsnamn som er att etter ein bygg eller ei migrering i staden for det nettlesaren brukte. Viss det der står eit internt vertsnamn, vert nettlesaren send ein stad han ikkje kan nå, og inga endring av tunnelen rettar det.

Samanlikn den trygge og den utrygge basis-URL-en med dei offentlege namna framfor deg. Eit avvik i ein av dei gjev nøyaktig den omdirigeringa du stirer på.

Overskrifter frå ein klarert proxy er ein kontrakt

Når TLS sluttar i ein lastbalansar, ser applikasjonen rein HTTP og må få beskjed om noko anna. Innstillinga for offloader-overskrift namngjev overskrifta proxyen set, til dømes den videresende protokollen, og applikasjonen stolar på henne ved skjemavalg.

Den tilliten er ein kontrakt med éin proxy, ikkje ei generell løyve. Å godta overskrifta frå vilkårlege klientar lèt kven som helst hevde eit skjema, og difor høyrer ho berre heime der ein utpeikt proxy set henne. Viss overskriftsnamnet og åtferda til proxyen ikkje stemmer, genererer applikasjonen omdirigeringar til eit skjema nettlesaren aldri brukte, og løkka lukkar seg. Kontroller proxykonfigurasjonen og applikasjonsinnstillinga saman, og tøm deretter konfigurasjonsbufferen slik at endringa trer i kraft.

Når løkka er ein sesjon, ikkje ei rute

Ei kjede som alltid går attende til innlogging er vanlegvis eit informasjonskapselproblem. Undersøk om sesjonskapselen vart utferda for vertsnamnet nettlesaren faktisk brukte, og om han vart merkt som trygg på ei tilkopling nettlesaren reknar som trygg. Ein informasjonskapsel som er avgrensa til feil domene, gjev ei innloggingsløkke som ser nøyaktig ut som ein rutingfeil.

Rett opp det påviste avviket hos eigaren, anten det er basis-URL-en, informasjonskapselens domene eller proxykontrakten, og test deretter heile navigasjonen på nytt i staden for å sjå på at éin 302 forsvinn. Å slå av HTTPS-krav for å bryte løkka byter ei omdirigering mot eit verre problem. Når endringa er gjord, kontroller tunnelen separat: be om ein kjend privat ressurs og stadfest at han kjem, slik at neste omdirigering har ei rein grunnlinje å samanlikne med.