For the purpose of auth specifically, I think it's worth considering circumventing the client side entirely.

Right now, any framework with auth support retains a copy of the active user's session on server-side. There isn't any reason for us to do a round-trip from server->client->server just to fetch that data.

It's healthier for us to develop an implementation on a per-framework basis for server-side auth access. For example, Django SessionMiddleware stores the current Django auth session within the websocket scope. We could develop, or have dependencies for, ASGI middleware that does the same.

Yeah, i wasn't considering the XSS risks until now, thanks @rmorshea .

I had passed through issue #828 but wasn't able to reproduce the idom-auth-example-sanic suggestion. Because it uses the old nomenclature of the project i wasnt able go around and fix it. If there is any updates in this matter i wold be happy to contribute.

Anyway, even if not used for authentication purposes, maybe my use_local_storage method could be useful in the future.

As a general rule, you should never trust anything coming from a client.

The only thing that can be trusted is the server. The client should only be used to store non-important (or high entropy) data.

Ok, I think I understand. In your implementation, you sync local storage with the server before the first render. At that point, we just assume that local storage is always controlled server-side.

Yes, i thought that was the most practical way.

We could even add a security layer in the future by natively encrypting the localStorage in the server side before sending it to the client. This would guarantee integrity and security of data stored there.

Do you think we could apply this logic to other features listed in #1075 ?

Unfortunately, sending it before first paint ultimately slows down the speed of first paint. This ends up being an exponentially larger problem as more clients connect to one server.

Leaving technical questions aside, here's what the two interfaces would look like:

# SYNC USAGE
local_storage = use_local_storage()
value, set_value = use_state(local_storage.get_item("value"))
@use_effect
def set_local_storage_value():
 local_storage.set_item(value)

# ASYNC USAGE
local_storage = use_local_storage()
value, set_value = use_state(None)
@use_effect
async def get_local_storage_value():
 set_value(await local_storage.get_item("value"))
@use_effect
async def set_local_storage_value():
 await local_storage.set_item(value)
if values is None:
 # value has not loaded yet
 ...
else:
 # value has loaded
 ...

Regardless of what approach you take set_item ought to be in an effect since it's a "side effect". So the main difference is that in the async API you need an extra effect to retrieve the value.

@rmorshea yeah, its working like that.

Adapted this sample to the async usage.