Better error messaging when out of local storage quota?

[woldie]

Better error messaging when out of local storage quota?

[frederikprijck]

Thanks for reaching out, I am not sure I fully understand how to reproduce this, can you please elaborate on the exact reproduction steps?

I tried the following:

• Call loginWithRedirect, this does not use local storage but does use session storage. Emulating this throwing an exception works as expected and I get an expection without being redirected to Auth0. So for me, this is already where it ends, I am not redirected to Auth0, I don't get any white page, and I get a clear error in the console (the own thrown by sessionStorage.setItem).

Just to be clear, what I did was instead of calling sessionStorage.setItem, I used throw new DOMException('TEST - CAN NOT WRITE TO LOCAL STORAGE'); , and this is the output:

Even though this is not using a real quota exceeded error, this simulates the same situation when setItem would throw any error upon calling loginWithRedirect.

I am testing with the Simulacrum Auth.0 simulator,

I am not aware of this and have never used it. I do not think it should impact the issue at hand here, but I do recommend trying with real Auth0 just to be sure.

[woldie]

Thanks for reaching out, I am not sure I fully understand how to reproduce this, can you please elaborate on the exact reproduction steps?

I tried the following:

* Call loginWithRedirect, this does not use local storage but does use session storage. Emulating this throwing an exception works as expected and I get an expection without being redirected to Auth0. So for me, this is already where it ends, I am not redirected to Auth0, I don't get any white page, and I get a clear error in the console (the own thrown by sessionStorage.setItem).

Hm. Perhaps I was running into Firefox edge cases or session storage quota bugs when local storage was near capacity. I have thousands of keys and a years-old Firefox profile, so perhaps it was gremlins. In any case, sadness.

One thing I did not think to note in my original bug report was that I annoy the user by asking them to grant persistent storage before allocating localstorage by using navigator.storage.persist. Looking at how much storage I am granted when I try to allocate all the space, it seems that I am allowed to get over 9MB. If Firefox is letting me allocate so much, and the quotas are supposed to be 5MB for session and 5MB for local, I'm probably being allowed to impinge on session storage's quota?! That seems like a bug, but I'm happy about that because I get so much more storage. Can you tell me, assuming this bug is intended behavior, how much space should I reserve from the 10MB quota for Auth.0? I don't believe I have any other Session Storage consumers than Auth.0, so I will give you whatever you require with padding.

Here is what I see in terms of free space right now.

I am testing with the Simulacrum Auth.0 simulator,

I am not aware of this and have never used it. I do not think it should impact the issue at hand here, but I do recommend trying with real Auth0 just to be sure.

Oh, it would be smashing if you gave us a first-party localhost auth.0 simulator! A simulator lets me do TDD and integration testing without needing the internet or your servers. Think about the extra sneaky market advantages you would have by improving the developer experience that way! ;) There's a very good reason why Dynamo has a Dynamo Local and why Azure had to catch up with their Azure Cosmos Emulator.

I had to jump through fiery hoops to automate the Simulacrum Auth.0 Simulator and it only simulates the login and token flows. Would love to also have mock Auth.0 Management API's for my server side instead of wiremocking them myself, probably imprecisely compared to what you would produce.

[frederikprijck]

I cant tell you how much storage you should account for, as you can put all kind of things in your token that are outside of our control.

Regarding the local solution, feel free to pass feedback on https://auth0.com/feedback.

Alternativly, u can use node-oidc-provider to spin up a local oidc server and interact with that for your tests, we do the same for our integration tests.

[woldie]

Ok, it sounds like I have a lot of control over how much session storage is used.

Thanks for the tip, I will bookmark node-oidc-provider and investigate when I return to server-side testing.

I will close this ticket, but please reopen if you need anything from me. Thanks for looking into this.