Et skript som kjører på en nettside har ingen generell innstilling som endrer nettleserens utgående proxy. En nettleserutvidelse kan ha ekstra tillatelser, men den kjører under en annen sikkerhets- og konfigurasjonsmodell.

Denne forskjellen forsvinner i gamle forumsvar. Kode som bruker privilegerte Firefox-internals, eldre utvidelsesmoduler eller forlatte add-on-SDK-er var aldri et vanlig nettside-API. Å lime inn et slikt utdrag på en side gir ikke disse rettighetene.

Bruk nettleserens utvidelses-API

En Firefox-utvidelse kan bruke det dokumenterte proxy.settings-API-et med de nødvendige tillatelsene. Chrome tilbyr sitt eget proxy-utvidelses-API. Konfigurasjonsmodellene deres er forskjellige; sjekk manifestkravene og de støttede innstillingene for nettleseren du sikter mot.

En utvidelse bør også ta hensyn til retningslinjer eller andre utvidelser som styrer samme innstilling. Et vellykket API-kall er ingen grunn til å anta at hver destinasjon nå følger ruten du hadde tenkt. Undersøk den resulterende konfigurasjonen og bevar brukerens mulighet til å gjenopprette den.

Å endre en fetch-URL endrer destinasjonen

En nettside kan kalle en applikasjonsserver som videresender en forespørsel på dens vegne, underlagt nettleserens webregler. I det designet kobler nettleseren til den applikasjonsserveren. Den har ikke installert en generell nettleserproxy eller endret ruten urelaterte faner bruker.

På samme måte endrer det ikke forbindelsens kildeadresse å sende en header med en annen IP-adresse. En destinasjon kan tolke betrodd videresendingsmetadata etter sin egen policy, men nettverksstien er et eget faktum.

Hvis målet er en IP-bytteproxy for surfing, velg en passende oppføring fra listen over gratis proxyer og sett opp en støttet nettleserproxy eller en autorisert utvidelse. Hvis målet er ekstern fetch for én webapplikasjon, design den funksjonen rundt dens faktiske server- og nettlesergrenser.

Relaterte artikler