Nuxt.js Auth Module Error (Actually a Docker Links Problem)
No... I'm sure it was working fine... After logging in with Auth in Nuxt.js, an error suddenly occurs when I refresh. No, to be precise, when I refresh, SSR rec
GGAMI·
No... I'm sure it was working fine...
After logging in with Auth in Nuxt.js, an error suddenly occurs when I refresh.
[Vue warn]: The client-side rendered virtual DOM tree is not matching server-rendered content. This is likely caused by incorrect HTML markup, for example nesting block-level elements inside <p>, or missing <tbody>. Bailing hydration and performing full client-side render.
No, to be precise, when I refresh, SSR recognizes that Auth is absent and loads in a false state, while on the client side it gets the user ID and renders as true, so the two renderings are different....
I think the issue above is probably the right one, but I just can't solve it.. No, I'm sure I set the config value to
localStorage: null, and I'm sure it used to work, but now it doesn't again. Sigh..... What on earth am I supposed to do about this.. I'm sure there wasn't any problem, but it seems like this error suddenly started happening..
Ugh.. what on earth is wrong with you......
Sigh,, I just finished setting up Docker,, and after sorting out the refresh token and token authentication..
I was about to start working on the admin page.. but I can't get any work done at all..
I don't know why it's so hard to use Nuxt.js's Auth Module.. (so annoying....)
It works, then it doesn't.. It works fine on Windows.. but when I switch to Docker, it stops working again.. lol, I have no idea what on earth is causing it..
When you log in, that value is saved. Then, when you refresh, that cookie value is sent along; if that cookie value is present, on the server side in nuxtServerInit
it calls it with that, retrieves the value, and saves it. Then it stores it in Auth/user and immediately outputs it..
So during server rendering, it gets and outputs it as present, and there's no problem on the client side either.
However, if the Token value called during server rendering fails, it will be tried once more on the client side too..
So... then why can't it make the call in Docker?
First, I registered the Host using http.routers through Traefik. The access domain
And I set nuxt.js's backend.port to 3000, so accessing domain:80 would connect to port 3000 of that container.
I think the reason it never returns true and instead returns false only in Docker is that when refreshing and connecting to that Nuxt Docker container, the Cookie value is not sent along in the Header.
req.headers.cookie
There's no other explanation...
So what I need to do is.. check whether the Cookie value is sent along when calling through Traefik from Docker..
Ugh.. I posted asking for help in a GitHub issue and all that.. but... nothing... just nothing... I guess this module itself isn't popular to begin with... I spent the whole day staying up all night, constantly switching between Docker and Windows.. this has to be the Cookie part in Traefik... I'm going to go look for it now.. I'm not going to sleep until I solve it..
Ah... It’s being passed correctly as Bearer in Authorization...
I think I know why... I figured it out.. I searched for so many things..
The axios URL is wrong.. Why?..
The Docker container network is connected through a single bridge called frontend from the start.. Since it’s calling the URL using the backend Host, the call doesn’t work!!!!!!!!!!
This is 20000% it..... The API URL has to be set to the Docker network address..
Well... then, when running the service normally, external access is available, so using the URL should work fine..
But in the DEV environment, it’s localhost.. since external access isn’t possible, do the containers have to be connected to each other?? Is this something Traefik provides..? I’ll have to look into it..
So.. SSR can’t access api.dev.localhost (from the Docker container)..
But the client is the host, so I’d set it up so that api.dev.localhost could be reached through Traefik..
So on the Docker server side, api.dev.localhost can’t be called, and that’s why it keeps treating the session as dead..
So, the way I handled it was..
I added links to the docker-compose file. links:
- backend:api.dev.localhost
And just like that.. ping api.dev.localhost works without any problems from nuxt.js!!
I wondered if it could be done with external_hosts.. but I just used links..
The strange thing is, it works even though it’s not registered in hosts.. why..?
Well.. As of today, I’ve dockerized the Laravel Backend and Nuxt.js Frontend.....
(Whew.. now, when I wake up, I think I’ll have to handle refresh tokens and so on..)
With SSR, when you refresh, it seems like you end up having to do it twice: once loading from the server and once on the client.... This is giving me a headache.. hmm..
And additionally... in the Auth Config
'resetOnError': true,
When configured this way, if it can’t retrieve the payload using the token, it just immediately discards the token. (It also prevents the client from trying.)
I do have a refresh method in mind...
With the resetOnError option enabled, when the backend refreshes, I’d like it to immediately switch to a new token value, fetch the data at the same time, and register the token right away..
And how should I handle it on the client..?