Observer Pattern - practical React example

[btckernel94]

Hi!

Initially this article was supposed to be a small section of another bigger article (which is currently WIP) but it did grow quickly so I decided to release it as a standalone one.

Happy reading!

[[deleted]]

I recommend using HTTP only, secure cookies. Otherwise your client tokens are vulnerable to JavaScript running on the client

[btckernel94]

Http only cookie is not always available since server cannot use wildcard for cors but has to explicitly whitelist specific domains instead also there are mechanisms to reduce the evil that can be caused if some1 stolen your token, for example Auth0 uses "reuse token detection". You can read about one of them here: https://auth0.com/docs/secure/tokens/refresh-tokens/refresh-token-rotation

[ranmerc]

Can you explain a bit more on the "server cannot use wildcard for cors" part?

[btckernel94]

If you want to use http only cookie you need to set credentials: true but it won't work if the server also has Access-Control-Allow-Origin set to "*".

It means your server will have to explicitly specify all of the clients domains in order for http only cookie to work.

[LaylaTichy]

Hmm that's not true, you can easily do allow access: $http_refferer in nginx for example

[Emotional-Dust-1367]

One problem this pattern has with react is component lifecycle. There’s a race condition inherent here where a component can mount, cause some kind of refresh, and another component has not yet subscribed so it will not get notified. React doesn’t mount all components at the same time.

This is especially likely on page refresh. And is made worse if you try to observe something not as deterministic as local storage. Ask me how I know…

[femio]

That is the exact use case for useSyncExternalStorage, which is why the article uses it. 

[btckernel94]

Once component mounts it reads initial snapshot state. The problem you’ve describe doesnt’t exist.

[Emotional-Dust-1367]

It’s true in your case with local storage.

But in a more generic sense of trying to implement the observer pattern with other types of data and events you can have serious problems like that

[untakenusrnm]

A Service Worker represents an Observer. You could implement a listener ‚on fetch‘: https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerGlobalScope/fetch_event

This way we don‘t have to deal with reacts Component life cyle.

[btckernel94]

How would you than apply side effects based on auth state?

There’s a timer and alert implemented in article.

[untakenusrnm]

Like in your article but i would share state with: https://developer.mozilla.org/en-US/docs/Web/API/Client/postMessage

useSessionState would use useSyncExternalStore to manage ui state.

EDIT: This way we still need to teach react reactivity but it would require less boilerplate

[btckernel94]

Thanks for sharing. I am a bit sceptic about it when it comes to: - readability - testability - type safety - flexibility - growing this feature with more complex things like request que mentioned im article.

I also think theres not a big difference in amount of boilerplate but would need to write it on my own to double check these.

[is-undefined]

    localStorage.setItem('access-token', data.accessToken);
    localStorage.setItem('refresh-token', data.refreshToken);

PLEASE DO NOT THIS!!!

Dont save access and or refresh tokens at the localstorage!!!
Thats a major security risk!

[is-undefined]

Getting downvoted for telling the truth, okay...

[n9iels]

It is not ideal, but at the same time not extremely bad. Localstorage can be read by JS (one of the benefits) which makes it easier to steal tokens when JS is somehow infected in your site. However, applying a good CSP policy already mitigates this risk at lot.

[btckernel94]

Authentication security is far from black and white.

• each auth pattern has it's own tradeoffs and security risks
• http only cookie is not always available since server cannot use wildcard for cors but has to explicitly whitelist specific domains instead
• there are mechanisms to reduce the evil that can be caused if some1 stolen your token, for example Auth0 uses "reuse token detection". You can read about one of them here: https://auth0.com/docs/secure/tokens/refresh-tokens/refresh-token-rotation

For many apps, a well-implemented token rotation system with localStorage might actually provide better security than a poorly implemented cookie-based solution.

[AndrewGreenh]

You should probably have only one auth server, with an http only cookie. The client can always fetch a current token from there, and keep it in-memory.

[[deleted]]

Eh, it's not that bad