Proxy calls to localStorage.getItem() for sandboxing and ensuring value is current

[westonruter]

Is your feature request related to a problem? Please describe.

I was experimenting with sandboxing a script to block access to localStorage, but I found that this was not currently possible. Namely I configured Partytown as follows:

var partytown = {
    apply: (opts) => {
        console.log('apply:', opts.name);
        if (opts.constructor === 'Window' && opts.name.startsWith('localStorage.')) {
            return opts.prevent;
        }
        return opts.continue;
    }
};

I then had this script on the page:

<script type="text/partytown">
localStorage.setItem('greeting', 'Hello World');
console.info(localStorage.getItem('greeting'));
localStorage.removeItem('greeting');
localStorage.clear();
</script>

In the console I then see only these calls logged out:

apply: localStorage.setItem
apply: localStorage.removeItem
apply: localStorage.clear

The call to localStorage.getItem is missing. This appears to have been done intentionally, as the entire localStorage data is sent to the worker when it is initialized:

partytown/src/lib/sandbox/read-main-platform.ts

Lines 74 to 81 in ab532e6

	const initWebWorkerData: InitWebWorkerData = {
	$config$,
	$interfaces$: readImplementations(impls, initialInterfaces),
	$libPath$: new URL(libPath, mainWindow.location as any) + '',
	$origin$: origin,
	$localStorage$: readStorage('localStorage'),
	$sessionStorage$: readStorage('sessionStorage'),
	};

The initially-synced value is then referred referenced locally instead of invoking callMethod to obtain the value from the main thread:

partytown/src/lib/web-worker/worker-storage.ts

Lines 24 to 42 in 4740cea

	let storage: Storage = {
	getItem(key) {
	index = getIndexByKey(key);
	return index > -1 ? getItems()[index][STORAGE_VALUE] : null;
	},
	setItem(key, value) {
	index = getIndexByKey(key);
	if (index > -1) {
	getItems()[index][STORAGE_VALUE] = value;
	} else {
	getItems().push([key, value]);
	}
	if (isSameOrigin) {
	callMethod(win, [storageName, 'setItem'], [key, value], CallType.NonBlocking);
	} else {
	warnCrossOrgin('set', storageName, env);
	}
	},

Was this done for the sake of performance?

As it stands right now, it is quite possible for the storage in the worker to get out of sync with the storage in the main thread. If the main thread calls localStorage.setItem() after the worker is initialized, the stored value is not seen in the worker. There would seem at least a need to add a storage event listener on the main thread and continuously sync changes back to the copy in the worker. Nevertheless, this could be avoided if calls to localStorage.getItem() were proxied. This would also eliminate duplication of the localStorage data, reducing memory usage (although at the cost of slower execution time).

Describe the solution you'd like

Discontinue sending the entire localStorage and sessionStorage datasets into the worker at initialization, and instead proxy all calls to getItem to obtain the canonical current value from the main thread.

[n0th1ng-else]

Hey any update on this issue? I find it makes a lot of sense, considering we can control the cookies, I wonder what is the reason to leave localStorage untracked?

[gioboa]

Hi @n0th1ng-else I didn't look at this issue. would you like to drop a PR for that?

[n0th1ng-else]

@gioboa could you please check the PR when you have time? looking forward to hear what you think

• fix: proxy localStorage and sessionStorage (closes #293) #548