sessionStorage and localStorage no longer work with Lightning Web Security with components that have two namespaces

[AllanOricil]

@manuel-jasso

Description

sessionStorage and localStorage no longer work with Lightning Web Security with components that have two namespaces

In the picture below you can see that my value was set with namespace c and key '123'

But I can't read it from another page with another lwc. Even when it belongs to namespace c

Steps to Reproduce

After enabling Lightning Web Security

1- Create two pages (A and B) in an Experience/Community Site

2- Add a component to page A that does this:

connectedCallback(){
localStorage.setItem('id', 1);
sessioStorage.setItem('id', 1);
}

Make sure this component is using two different namespaces (like c and vlocity's)

3- Add another component to page B that does this:

connectedCallback(){
console.log(localStorage.getItem('id', 1));
console.log(sessioStorage.getItem('id', 1));
}

This can use namespace c only

4- Publish your community

5 - Open page A (do not use preview mode. Open the page with your User)

6 - Verify both local and session storages have id = 1 and are related to namespace [c]

7 - Now navigate to Page B

8 - Verify console did not print 1 because those values were not located

Obs: Im not sure if it is a Communities specific issue. Obs: I think my issue is because my component that sets those storages is using two different namespaces (c and vlocity). And the component that reads those storages only uses the c namespace. Obs: Im not sure if this worked before. But there are people saying that even with lightning locker it was possible to use session storage to retrieve data when going to a different page. The only limitation was that both components should use the same namespace. Is is true?

Expected Results

Session and Local Storages should allow components to share data between different pages on the client side

Actual Results

Session and Local Storages don't work anymore

Browsers Affected

I tested on chrome only

[AllanOricil]

@manoel-jasso

According to this page https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.security_lwsec_architecture

Components from different namespaces shouldnt be able to access resources like localstorage and sessionstorage from one another. But what is the case when Component A makes use of two namespaces and sets a value on either session or local storage? My guess is that this value won't be accessible from any of those two namespaces because this is what is happening to me here haha. But this is kind weird because since my value is set using namespace C (I did not even choose to save on namespace C), as I showed in the above picture, it should be accessible from any other component that uses namespace C, right?

So maybe the documentation is not covering this scenario.

Or maybe I understood the documentation wrong. If I have two Components using namespace C only, will they be on the same sandbox? Or will each be on a different sandbox that belong to namespace C? What happens if my component has two namespaces? Which sandbox is this component running on? Can a Sanbox on namespace X share data using local/session or cookies between other component that also belong to namespace X? How do I tell which namespace my component belongs to (is it by using "runtimeNamespace prop on the meta.xml file? )

[AllanOricil]

I also added this to both components A (uses two namespaces) and B (use just the c namespace) :

<runtimeNamespace>vlocity_cmt</runtimeNamespace>

and I have the same result. I can't read session/local storage

[AllanOricil]

Something caught my attention.

LSSIndex:SESSION{“namespace”:“vlocity_cmt”} key is on the vlocity_cmt namespace

while its value is on the c namespace LSKey[c]referenceId

This seems kind weird and maybe that is why my component on page B can't read this value I stored

[manuel-jasso]

Hi @AllanOricil, thanks for your report. We need to analyze the details to give you a better answer, but from your description, it looks like this is working as designed. Components from namespace "foo" are not allowed to read/write LocalStorage data from namespace "bar", and vice versa.

In regards to the runtimeNamespace, this is a Legacy Locker feature, it has no effect on LWS.

But this makes me wonder: did you have this same scenario working on Legacy Locker before?

Thanks @nolanlawson for the ping.

[AllanOricil]

Hi @AllanOricil, thanks for your report. We need to analyze the details to give you a better answer, but from your description, it looks like this is working as designed. Components from namespace "foo" are not allowed to read/write LocalStorage data from namespace "bar", and vice versa.

In regards to the runtimeNamespace, this is a Legacy Locker feature, it has no effect on LWS.

But this makes me wonder: did you have this same scenario working on Legacy Locker before?

Thanks @nolanlawson for the ping.

Yes. @depill, the architect on my team, followed the example I described here and his setup worked. The only difference he noticed is that he did not use two namespaces on the component that is saving values on the session/local storage. I think there is some kind of bug here because when I look into the saved value, the Key is under vlocity_cmt namespace and its value is on the c namespace. Check the image I posted on the last comment I left here. Shouldn't the Key and the Value be on the same namespace? Another weird thing is that no matter which namespace I use, I simply can't read that saved value. It is unreadable.