Use Async Storage API in favor of synchronous mutable storage API

[dan-f]

This change enables this library to work in contexts where localStorage is not available (e.g. a web worker or in a popup window which has to ask its parent to store data using window.postMessage).

[dan-f]

Did folks get a chance to look at this? This would directly unblock nodeSolidServer/solid-auth-client#24 and nodeSolidServer/solid-auth-client#19

[dmitrizagidulin]

What's the use case / requirement for async storage? (Server-side and webworker auth would still work fine in the current setup, if you pass along the serialized session to the webworker).

[dan-f]

What's the use case / requirement for async storage?

As I mentioned, the use case is to be able to run this library within a context where there is no access to a synchronous IO interface like localStorage. The relevant issues are nodeSolidServer/solid-auth-client#24, and nodeSolidServer/solid-auth-client#19:

• In a popup window which could potentially be on a different domain
• In a web worker

Server-side and webworker auth would still work fine in the current setup, if you pass along the serialized session to the webworker

The problem is that we'd then have to deserialize the session from the rp, which I don't think is an exposed interface.

Some thoughts:

1. Supporting async IO is a pretty reasonable expectation these days. My understanding from the comment here is that persistent storage in browsers is a supported use case.
2. Another option is to modify this library so that it does not actually need to write to the session object, but that seems like it would be a lot more work.

[dmitrizagidulin]

In a popup window which could potentially be on a different domain

The popup window should not be using an RP instance (that is way too heavyweight); the popup's only function is to help the user select the provider, and post that url back to the parent window (where the RP client creates the authz url and redirects the popup to it). But even if your architecture requires that the popup window uses the RP client, see the web worker discussion below.

In a web worker
The problem is that we'd then have to deserialize the session from the rp, which I don't think is an exposed interface.

Once the user logs in, no RP instance is actually needed for authenticated fetches. (The PoPToken.issueFor() method that the authenticated fetch uses is a static method.) So the workflow would go, roughly:

1. User logs in
2. Main window eventually calls currentSession() (which validates the auth response), and returns a Session object (which includes the client id and session keys needed for authenticated fetches). (If you're not using the solid-auth-client's currentSession, the rp.validateResponse() method also returns a Session object).
3. Post the serialized Session object to the web worker (or from the popup window to the main window, if required).
4. Web worker deserializes (json parses) the Session object, and is ready to call fetchWithCredentials(session, url, options) as needed (which calls the static RP client method PoPToken.issueFor(url, session)).

After login, no further mutations are made to the Session object, and none of these workflows require async storage.