Auth-module: loggedIn is false and user is not available in middleware when executed in server side. SSR:true and target as static

[ramsane]

Version

module: auth-next : 5.0.0-1610115973.9fdaa66
nuxt: 2.14.6

Nuxt configuration

mode:

• [x] universal with targe: static
• [ ] spa

Nuxt configuration

auth: {
redirect: {
login: '/login',
logout: '/login',
home: false,
},
strategies: {
local: {
endpoints: {
login: {
url: 'users/login/',
method: 'post',
propertyName: 'token',
},
logout: false,
user: false,
},
token: {
type: 'Token',
},
},
},
}
```

But it updates when the component gets loaded in the client side.

What is expected?

• It should have loggedIn and user in middleware when executed in the server

  What is actually happening?

• The information is simply not there.

  Steps to reproduce

• I can't because we are using with local api for authentication.

  Checklist

• [x] I have tested with the latest Nuxt version and the issue still occurs

• [x] I have tested with the latest module version and the issue still occurs
• [x] I have searched the issue tracker and this issue hasn't been reported yet

[jbiddulph]

I'm getting this too!
been trying/looking to fix for over a week now

[JoaoPedroAS51]

Hi @ramsane! This seems to be misconfiguration. Try the following config:

auth: {
  redirect: {
    login: '/login',
    logout: '/login',
    home: false,
  },
  strategies: {
    local: {
      endpoints: {
        login: {
          url: '/users/login/',
          method: 'post'
        },
        logout: false,
        user: false, // must define the user endpoint to have user data
      },
      token: {
        property: 'token', // the token property should be set here, `propertyName` in endpoint was deprecated.
        type: 'Bearer', // should be "Bearer" if is jwt token
      },
    },
  },
}

I believe the token will be correctly handled now, but you still need to define the user endpoint, otherwise user will not be available.

[ramsane]

I have a backend that uses Token <token_string>. So, I need to have type as Token.

When I access $auth, loggedIn is False and token is set. And I wrote a simple plugin that fetches the user based on the token and set the user manually. I got that part. Thanks for clarifying that.

Now, In login page, I wrote a middleware that checks for whether user is loggedIn or not and redirects if the user is authenticated. But $auth.loggedIn is false and token is not set in server to get the userInfo.

But as soon as the page got loaded to the client, it gets data from cookies(probably) and makes loggedIn as true and get's the token. I can fetch the user and set the user with $auth.setUser(). This flow works perfectly fine.

So, I think that the $auth not able to get loggedIn information when executed from the server.

I hope the problem is clear now.

[JoaoPedroAS51]

@ramsane Ok, thank you for clarifying that! :)

Can you make a repro? As this is a specific use case, I'll not be able to look at this issue without a repro.
You can use this CodeSandbox template if you want.

I know you said you can't because you're using with local api for authentication. But I think if the problem is related to middleware and server, then this issue should happen in our demo code too.

[ramsane]

It works fine in that demo. But I can see that, we are mentioning auth.js file in server middleware. Do I have to do that too.

If required, I can share the complete config too. right now, I switched to spa(ssr: false) so that the middleware executes only on the client side. It works fine now. But I wanted to know the reason that's all.

[jim-toth]

I'm facing the same issue. On a cold boot (local dev or on GCP App Engine) loggedIn is true from localstorage but false on SSR. I can re-create this in my project locally by:

1) Launching app in dev env (npm run dev)
2) Logging in
3) Fully closing browser
4) Fully closing app (killing the terminal)
5) Re-launching app (npm run dev)
6) Re-opening browser, and logging in

Because my home page is different depending on the user's authentication status, this results in an SSR warning, which then leads to an even more cryptic error:

[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.
TypeError: Cannot read property 'toLowerCase' of undefined
    at emptyNodeAt (vue.runtime.esm.js?2b0e:5867)
    at VueComponent.patch [as __patch__] (vue.runtime.esm.js?2b0e:6508)
    at VueComponent.Vue._update (vue.runtime.esm.js?2b0e:3945)
    at VueComponent.updateComponent (vue.runtime.esm.js?2b0e:4060)
    at Watcher.get (vue.runtime.esm.js?2b0e:4479)
    at new Watcher (vue.runtime.esm.js?2b0e:4468)
    at mountComponent (vue.runtime.esm.js?2b0e:4073)
    at VueComponent.Vue.$mount (vue.runtime.esm.js?2b0e:8415)
    at init (vue.runtime.esm.js?2b0e:3118)
    at hydrate (vue.runtime.esm.js?2b0e:6378)

Here's my config:

  auth: {
    redirect: {
      login: '/login',
      logout: '/',
      home: '/',
      rewriteRedirects: true,
    },
    strategies: {
      local: {
        scheme: 'refresh',
        token: {
          property: 'token',
          maxAge: 1800
        },
        refreshToken: {
          property: 'refresh_token',
          data: 'refresh_token',
          maxAge: 60 * 60 * 24 * 30
        },
        user: { property: 'user' },
        login: { url: '/auth/login', method: 'post' },
        logout: false,
        user: { url: '/auth/user', method: 'get' }
      }
    }
  },

And here is the token response:

{
  user: UserViewModel | null
  token: string | null
  refresh_token: string | null
}

And here's my default.vue:

<template>
  <v-app>
    <v-app-bar v-if="$auth.loggedIn"></v-app-bar>
    <v-main>
      <nuxt v-if="!$slots.default" />
      <slot />
    </v-main>
  </v-app>

[dkjensen]

Having the same issue

[vanling]

Same issue here on 5.0.0-1610809099.bcf293f

[marssantoso]

Hey guys. Currently experiencing this as well (5.0.0-1618502945.2770f1f).

Does this mean the auth middleware doesn't support SSR? Or is there any workaround besides switching to SPA?