JavaScript Web Worker - błąd naruszenia bezpieczeństwa

pytanie zadane 28 sierpnia 2020 w JavaScript przez niezalogowany

Cześć!

Od jakiegoś czasu eksperymentuję z JavaScriptem, aby go lepiej poznać, i przy okazji piszę mini-gierkę. Napotkałem schody przy używaniu JavaScriptowego Web Workera. Gdy otwieram stronę (lokalnie jako plik) dostaję błąd w konsoli:
Błąd naruszenia bezpieczeństwa: treść zawarta pod adresem „file:///[...]/src/index.html” nie może wczytać danych z „file:///[...]/src/scripts/keys-handling.js”.

Poniżej kolejno wycinki plików: index.html, main.js, keys-handling.js (w tym pliku jest przykładowy kod).

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    [...]
    <link rel="stylesheet" href="style.css">
    <script src="main.js"></script>
</body>
</html>

const keysHandling = new Worker('scripts/keys-handling.js');

let map = {};
onkeydown = onkeyup = e => {
    map[e.code] = e.type == 'keydown';
    if (map['KeyA'] && map['KeyS']) {
        alert('Potas');
        map = {};
    }
}

Czy ktoś wie, jak mógłbym rozwiązać ten problem?

1 odpowiedź

odpowiedź 28 sierpnia 2020 przez Comandeer Guru (601,490 p.)
wybrane 29 sierpnia 2020

Najlepsza

Najłatwiej byłoby po prostu odpalać to z jakiegoś lokalnego serwera, choćby XAMPP-a. Jeśli odpalasz to wprost z dysku, to szybko natkniesz się na problemy z CORS, bo każdy plik jest traktowany jakby pochodził z innego originu (innej domeny).

komentarz 28 sierpnia 2020 przez ScriptyChris Mędrzec (190,190 p.)

Orientujesz się, czy tylko URLe korzystające z protokołu file są blokowane przez Same Origin Policy (zakładając, że reszta URLa spełnia reguły uznające go za tę samą domenę, a jedynie URI scheme to file)? W specyfikacji originu nie widzę wzmianki, żeby protokół file był w jakiś sposób wykluczony z SOP. A skoro przeglądarki w miarę zgodnie blokują zapytania z tego protokołu (chyba Firefox kiedyś na to pozwalał), to czy jest jakiś dokument, w którym jest to spisane? Czy to bardziej jest traktowane przez przeglądarki jako implementation dependent?

Czy możliwe jest, że przeglądarki traktują też inne URI schemy na podobnej zasadzie (w kontekście SOP) co file - czyli trzeba brać pod uwagę indywidualne implementacje różnych przeglądarek, bo nie jest to ustandaryzowane?

1	komentarz 28 sierpnia 2020 przez Comandeer Guru (601,490 p.) Istnieje koncept tzw. opaque origin. Zgodnie ze specyfikacją URL, file:// to jeden z nich. Tak, jest to rozrzucone po różnych dziwnych specyfikacjach… Prawdopodobnie Fetch też dorzuca kilka originów.

komentarz 29 sierpnia 2020 przez ScriptyChris Mędrzec (190,190 p.)

Nie rozumiem trochę dlaczego przeglądarka blokuje protokół file (który w wyniku serializacji domeny staje się null-em) przy SOP? Jeśli domena strony ma wartość null i próbuje się wysłać request pod URL z protokołem file, którego domena też ma wartość null, to skoro te wartości są takie same (tj. null == null), dlaczego SOP to blokuje?

I jak rozumieć definicję "opaque origin"?

An opaque origin An internal value, with no serialization it can be recreated from (it is serialized as "null" per serialization of an origin), for which the only meaningful operation is testing for equality.

Dla mnie nie za bardzo ma sens: "wewnętrzna wartość, której procesu serializacji nie da się odtworzyć, dla której jedyną sensowną operacją jest testowanie równości". O ile rozumiem, że nie można odtworzyć procesu serializacji nulla - bo poprawnie zserializowaną domenę raczej można sparsować (odtworzyć):

The serialization of ("https", "xn--maraa-rta.example", null, null) is "https://xn--maraa-rta.example".

- o tyle nie rozumiem czym jest operacja testowania równości (o ile jest czymś innym niż null == null)?

Chyba przydało by się przejrzeć implementację SOPa w silniku przeglądarki... :(

komentarz 29 sierpnia 2020 przez Comandeer Guru (601,490 p.)

Dla każdego pliku przy scheme file:// zwracany jest nowy origin:

Unfortunate as it is, this is left as an exercise to the reader. When in doubt, return a new opaque origin.

Dzięki takiej definicji, każdy plik jest innym originem. I z punktu widzenia bezpieczeństwa ma to sens (bo do niektórych plików JS nie powinien móc się dobierać).

komentarz 29 sierpnia 2020 przez ScriptyChris Mędrzec (190,190 p.)

Firefox zdaje się łagodniej traktować scheme "file://":

https://searchfox.org/mozilla-central/source/netwerk/base/nsNetUtil.cpp#2339

// For file scheme, reject unless the files are identical

To chyba nie jest zgodne ze specką? Chyba, że to zachowanie tłumaczy wspomniany wyżej fragment definicji opaque origin

An opaque origin

An internal value, with no serialization it can be recreated from (it is serialized as "null" per serialization of an origin), for which the only meaningful operation is testing for equality.