Eit skript som køyrer på ei nettside har inga generell innstilling som endrar den utgåande proxyen til nettlesaren. Ei nettlesarutviding kan ha ekstra løyve, men ho køyrer under ein annan tryggleiks- og konfigurasjonsmodell.

Denne skilnaden går tapt i gamle forumssvar. Kode som brukar privilegerte Firefox-innar, eldre utvidingsmodular eller forlatne add-on-SDK-ar var aldri eit vanleg nettside-API. Å lime inn eit slikt utdrag på ei side gir ikkje desse rettane.

Bruk utvidings-API-et til nettlesaren

Ei Firefox-utviding kan bruke det dokumenterte proxy.settings-API-et med dei naudsynte løyva. Chrome tilbyr sitt eige proxy-utvidings-API. Konfigurasjonsmodellane deira er ulike; sjekk manifestkrava og dei støtta innstillingane for nettlesaren du siktar mot.

Ei utviding bør også ta omsyn til retningslinjer eller andre utvidingar som styrer same innstilling. Eit vellukka API-kall er inga grunn til å tru at kvar destinasjon no følgjer ruta du hadde tenkt. Gransk den resulterande konfigurasjonen og ta vare på moglegheita brukaren har til å gjenopprette han.

Å endre ein fetch-URL endrar destinasjonen

Ei nettside kan kalle ein applikasjonsserver som sender ein førespurnad vidare på hennar vegner, underlagt webreglane til nettlesaren. I det designet koplar nettlesaren til den applikasjonsserveren. Han har ikkje installert ein generell nettlesarproxy eller endra ruta som urelaterte faner brukar.

På same måte endrar det ikkje kjeldeadressa til sambandet å sende ein header med ei anna IP-adresse. Ein destinasjon kan tolke trudd videresendingsmetadata etter sin eigen policy, men nettverksstien er eit eige faktum.

Viss målet er ein IP-bytande proxy for surfing, vel ein passande oppføring frå lista over gratis proxyar og set opp ein støtta nettlesarproxy eller ei autorisert utviding. Viss målet er ekstern fetch for éin webapplikasjon, design den funksjonen rundt dei faktiske server- og nettlesargrensene hans.

Relaterte artiklar