Access local storage from webWorker

Question

Can WebWorker access local storage?

If not, why? Is this problematic in terms of security?

Answer 1

No, localStorage and sessionStorage are undefined in the web search process.

You will need to call postMessage() back to the source code of the Worker, and this code stores the data in localStorage.

Interestingly, a website can use an AJAX call to send / receive information to / from the server to open up possibilities, depending on what you are trying to do.

Answer 2

Web workers have access to only the following functions:

• XMLHttpRequest
• Application cache
• create other web workers.
• navigator object
• location object
• setTimeout method
• clearTimeout method
• setInterval method
• clearInterval method
• importScripts method
• Json
• Worker

The window or parent objects are not accessible to the web worker, so you cannot access the local storage.

To establish the relationship between the window and the workspace, you can use the postMessage() function and the onmessage event.

Access to the DOM and the window will not be thread safe, as the child thread will have the same privileges as its parent.

Answer 3

You can use IndexedDB in WebWorkers , which allows you to store things locally in the keystore. This is not the same as localStorage, but it has similar use cases and can contain quite a lot of data. We use IndexedDB at WebWorkers at my work.

August 2019 EDIT:

There is a suggested API that may appear in the future (although it is currently available in Chrome Canary with the experimental web functions flag enabled). It is called KV Storage (KV stands for Key Value). It has an almost identical interface with the localStorage API and comes with JavaScript modules. It is built on top of the indexeddb API, but has a much simpler API. Looking at Spec , it seems that this will work in WebWorkers. For examples of how to use it, see the github specification page. Here is one such example:

 import storage, { StorageArea } from "std:kv-storage"; import {test, assert} from "./florence-test"; test("kv-storage test",async () => { await storage.clear() await storage.set("mycat", "Tom"); assert(await storage.get("mycat") === "Tom", "storage: mycat is Tom"); const otherStorage = new StorageArea("unique string"); await otherStorage.clear() assert(await otherStorage.get("mycat") === undefined, "otherStorage: mycat is undefined"); await otherStorage.set("mycat", "Jerry"); assert(await otherStorage.get("mycat") === "Jerry", "otherStorage: mycat is Jerry"); }); 

Here are the tests passing in Chrome Canary:

Although it is not necessary to use the kv repository API, the code below is a test environment used for the above code:

 // ./florence-test.js // Ryan Florence Basic Testing Framework modified to support async functions // https://twitter.com/ryanflorence/status/1162792430422200320 const lock = AsyncLock(); export async function test (name, fn) { // we have to lock, so that console.groups are grouped together when // async functions are used. for await (const _ of lock) { console.group(name); await fn(); console.groupEnd(name); } }; export function assert (cond, desc) { if (cond) { console.log("%c✔️", "font-size: 18px; color: green", desc); } else { console.assert(cond, desc); } }; // https://codereview.stackexchange.com/questions/177935/asynclock-implementation-for-js function AsyncLock() { const p = () => new Promise(next => nextIter = next ); var nextIter, next = p(); const nextP = () => { const result = next; next = result.then(() => p() ); return result;} nextIter(); return Object.assign({}, { async * [Symbol.asyncIterator] () { try { yield nextP() } finally { nextIter() } } }); }