Better error messaging when out of local storage quota?

[woldie]

Checklist

• The issue can be reproduced in the auth0-spa-js sample app (or N/A).
• I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
• I have looked into the documentation and API documentation, and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Description

My app uses a lot of local storage, it allocates until there is no space left and then unwinds its allocations to leave space for other services like Auth.0's localstorage cacheLocation.

Unfortunately, I did not unwind my allocations quite enough and got into a scenario where auth0-spa-js got QuotaExceededError failures trying to allocate from local storage. It got into a strange bind where the redirect failed and it returned to the login screen. When I hopped into the debugger, unfortunately I watched exceptions after the first login failure, so I missed the QuotaExceededError and instead saw the more confusing "Invalid state" come up, leading to hours of frustrating debugging marlarks. To confound things, I am testing with the Simulacrum Auth.0 simulator, and perhaps real Auth.0 would act differently. But, I was left trying to figure out if the simulator was messing up somehow as well.

Once I cleared all the cookies and local storage, I got a clean login, and that's how I came to understand the possibility for QuotaExceededError in my setup. The fault was mine, and is a situation that likely wouldn't occur for any other users than me. Nevertheless, I believe that auth0-spa-js should guard against QuotaExceededError in its allocations to local storage because it's silently swallowing that QuotaExceededError and going into retry logic that also fails - an odd situation.

I guess all I would ask is that if an allocation throws an unexpected exception that you log it loudly and proudly to the console or make it clear somehow that the fault wasn't the more common troubleshooting deadends like react props being sent to are misspelled or doing the [Object object] goofus, etc.

Reproduction

To test, exhaust all the local storage before attempting to login and see how it behaves.

Additional context

No response

auth0-spa-js version

2.1.2

Which framework are you using (React, Angular, Vue...)?

react

Framework version

2.2.1

Which browsers have you tested in?

Firefox

[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.