nuxt / http

Universal HTTP Module for Nuxt.js
https://http.nuxtjs.org
MIT License
229 stars 51 forks source link

Authorization headers set on the server are not persisted on the client #88

Closed felixdenoix closed 8 months ago

felixdenoix commented 4 years ago

Version

v0.3.8

Reproduction link

https://codesandbox.io/s/priceless-voice-3mnwh

Steps to reproduce

Set Authorization headers during nuxtServerInit action in the store, they won't be present anymore in the client $http instance ($http._defaults.headers) afterwards

What is expected ?

the Authorization headers set on the $http instance server-side should be present in the $http instance client-side

What is actually happening?

the headers are empty client-side

Additional comments?

Not sure if this behaviour is intended ( and thus if its an issue) but it feels a bit odd having to set the request headers on both sides attended that I'm setting the header using the client cookies whenever available and that the client context is supposed to be hydated by the server-side data, right ?

atinux commented 4 years ago

Hi @felixdenoix

Actually it's a normal behaviour, we don't share the state of the $http headers between client and server.

What I believe could be a nice enhancement though, is when you actually call $http.setToken() on the server (or maybe directly $http.setHeader()) to keep these updates to set it on the client directly as well.

This could have some side-effects if you only need to set some headers on the server for instance. cc @pi0

pi0 commented 4 years ago

Hi. I think besides side-effects, it can be a neat future but first need to discuss if it there is a general enough use-case to add this functionality to scope of http (instead of auth). Additionally, this is not a universal solution:

A simple solution, would be using a plugin instead of nuxtServerInit which by default runs on both environments, ability to access same context of nuxtServerInit. It is also possible to hydrate Authorization without need of store which i can share a code example.

One good use-case i can see for supporting this feature, is for SSR-exclusive flow that Authorization header generation is only possible on server-side.

both sides attended that I'm setting the header using the client cookies whenever available and that the client context is supposed to be hydrated by the server-side data

Security advice: Reading cookies on server (specially if they are http-only) and exposing for hydration (which makes them accessible by client js) is breaking browser security mechanisms. So be careful :)