Redirected to login after refreshing any protected page

[atymic]

Version

4

Reproduction link

http://todo.com

Steps to reproduce

Visit a protected route by clicking a nuxt-link, and it loads correctly.
Then refresh the page

What is expected ?

Protected page loads

What is actually happening?

Redirect to login

Additional comments?

Hi!

I'm a bit confused as to why this is happening. I'm using a pretty basic set up (local scheme, universal storage).

As soon as I refresh the page, I'm redirected (302 from nuxt) to the login page. I did a bit of debugging and this seems to be because loggedIn isn't set in the cookie state.

All of the other cookies are there, but i'm still redirected :(

I'll do some more digging and try find some more info & a repro

_{This bug report is available on Nuxt community (#c439)}

[atymic]

My current hackyish solution is to manually redirect back to the correct page from inside the login page:

 mounted () {
      if (this.$auth.loggedIn) {

        if (this.$auth.$storage.getUniversal('redirect')) {
          this.$router.replace(this.$auth.$storage.getUniversal('redirect'))
          this.$auth.$storage.removeUniversal('redirect')
          return;
        }

        this.$router.replace('/')
        return
      }

[truesteps]

I'm having the same issue, I tried checkout out older versions of my app to see if it would work but they unfortunately didn't. I fiddled around with my own middlewares that I had in place, whether they were redirecting me badly, but it seems to be the auth ultimately.

As OP mentioned I am using the basic local scheme, I didn't do anything to the auth since the first time I implemented it and after half a year of development and working fine, without updating my node_modules, it just stopped working.

[therhenals]

The same happens to me when I deploy the project in zeit now with nuxt/now-builder

[pushkin5241]

I had such a problem, I added the ip address to the token and then checked it on the server in middleware, whether it is equal to the ip address from the request.
And the reason was that when I updated the page (nuxt was turned on in the SSR mode and axios sends a request to the server before issuing the page), then the address in the request will be the address of your server

[dan-danciu]

I had this problem also.
I solved it by micromanaging auth :)
This might not be what you need but take a look.
So this is what I have:

auth: {
    strategies: {
      local: {
        endpoints: {
          login: false,
          logout: false,
          user: false
        }
      }
    }
  },

When logging in I do it with axios and I manually set up auth. I do this mainly because I need my app to handle refresh tokens so you could just call the $auth.loginWith instead:

await this.$auth.setToken("local", "Bearer " + access_token);

Then I get the user with axios as well and then I also give it to auth:

this.$auth.setUser(user.data);

This also sets the loggedIn flag on auth so my middleware looks like this:

export default function({ $auth, redirect }) {
  if (!$auth.loggedIn) {
    return redirect("/login");
  }
}

In the log out functionality I just clear local storage and do:
this.$auth.logout();

So I handle everything manually and it works out well in the end.

[truesteps]

So I figured it out and there is nothing wrong with the package at all as it is.

The underlying issue for me, was the fact that nodejs refused to accept the response from our BE server, since it didn't have a fullchain certificate, only an intermediate one and the response from the server was deemed as unsecure so nodejs just threw the response away without reporting any errors. I figured this out while trying to implement axios proxy as a last resort to try to fix this and the proxy was giving me unable_to_verify_leaf_signature error.

Which just showed me towards the right way.

Something to note: It worked fine with apache but we switched stack to nginx midway through development...

// Edit:
If this helps at least one of you to get rid of all the awful hacks that are here, I made the world a better place!

[lukaVarga]

For me, the issue was with cookie settings. Basically, setting a secure: true doesn't work on localhost (I haven't tried on a staging environment yet). So setting this did the trick

auth: {
    .......
    cookie: {
      options: {
        secure: false,
      },
    },
}

Note: After changing this (locally) between true and false, try it out in incognito mode (or make sure you clear your cookies first). Otherwise you might not see any difference (especially when changing it from false to true).

[leonelsanchesdasilva]

Had the same problem when publishing to Heroku (production).

First, it's good to provide a little bit of context:

Packages

  "dependencies": {
    "@fortawesome/fontawesome-free": "^5.10.2",
    "@nuxtjs/auth": "^4.8.5",
    "@nuxtjs/axios": "^5.9.5",
    "bootstrap": "^4.1.3",
    "bootstrap-vue": "^2.0.1",
    "chart.js": "^2.8.0",
    "fullcalendar": "^3.10.1",
    "google-charts": "^2.0.0",
    "jquery": "^3.4.1",
    "jquery-sparkline": "^2.4.0",
    "leaflet": "^1.5.1",
    "load-google-maps-api": "^2.0.1",
    "mapbox-gl": "^1.3.1",
    "noty": "^3.2.0-beta",
    "nuxt": "^2.11.0",
    "nuxt-i18n": "^6.6.0",
    "perfect-scrollbar": "^1.4.0",
    "sortablejs": "^1.10.0-rc3",
    "v-money": "^0.8.1",
    "vue": "^2.6.10",
    "vue-select": "^3.2.0",
    "vue-the-mask": "^0.11.1"
  },
  "devDependencies": {
    "@nuxtjs/eslint-config": "^1.0.1",
    "@nuxtjs/eslint-module": "^1.0.0",
    "@vue/eslint-config-prettier": "^5.0.0",
    "@vue/test-utils": "^1.0.0-beta.27",
    "babel-eslint": "^10.0.1",
    "babel-jest": "^24.1.0",
    "eslint": "^6.1.0",
    "eslint-plugin-nuxt": ">=0.4.2",
    "eslint-plugin-prettier": "^3.1.1",
    "eslint-plugin-vue": "^5.0.0",
    "jest": "^24.1.0",
    "lint-staged": "^8.2.1",
    "node-sass": "^4.12.0",
    "prettier": "^1.18.2",
    "sass-loader": "^7.1.0",
    "vue-jest": "^4.0.0-0"
  }

nuxt.config.js

export default {
  mode: 'universal',
  auth: {
    strategies: {
      local: {
        endpoints: {
          login: { url: '/auth', method: 'post', propertyName: 'token' },
          // login: false,
          // logout: { url: '/api/auth/logout', method: 'post' },
          logout: false,
          user: { url: '/auth/user', method: 'get', propertyName: 'user' }
          // user: false
        },
        tokenRequired: true,
        tokenType: 'bearer'
      }
    },
    redirect: {
      login: '/login',
      logout: '/login'
      // callback: '/',
      // home: '/'
    },
    cookie: {
      options: {
        secure: process.env.NODE_ENV && process.env.NODE_ENV === 'production'
      }
    }
  },
  env: {
    apiUrl: process.env.API_URL || 'http://localhost:5000'
  },
  ...
  router: {
    middleware: ['auth']
  }
}

Environment Variables

NPM_CONFIG_LOGLEVEL=error
NPM_CONFIG_PRODUCTION=true
NODE_ENV=production
NODE_MODULES_CACHE=true
NODE_VERBOSE=false
HOST=0.0.0.0
API_URL=https://api.myservice.com

Deployed successfully, but every single page reload not using a nuxt-link was showing the login page. @atymic 's hint made me write a small debug middleware like this:

/middleware/debug_auth.js

export default function ({ $auth }) {
    console.log($auth);
}

Then I've found something like this in the middle of logs:

UNABLE_TO_VERIFY_LEAF_SIGNATURE

So I figured that Axios was trying to call endpoints.user (my case, /auth/user) and having a problem with the certificate. Turns out I purchased this certificate last week, so it was very strange that my certificate wasn't being accepted by Axios.

Testing the API url with a SSL Checker like https://www.sslshopper.com/ssl-checker.html gave me a message like:

The certificate is not trusted in all web browsers. You may need to install an Intermediate/chain certificate to link it to a trusted root certificate. Learn more about this error [Link]. You can fix this by following Sectigo's Certificate Installation Instructions for your server platform (use these instructions for InstantSSL [Link]). Pay attention to the parts about Intermediate certificates.

Indeed, my certificate issuer sent me a .crt file and a bundle file (which has, in theory, my purchased certificate + the intermediate certificate), but Heroku was complaining about the key. I had to find the intermediate certificate pointed by the SSL Checker by name (my case, Issuer: Sectigo RSA Domain Validation Secure Server CA) and combine them using a text editor (the order matters: first my purchased certificate, then the intermediate certificate). With the new file, Heroku accepted the bundle file and the key, I ran the validation again and this time the message was

The hostname (api.myservice.com) is correctly listed in the certificate.

I see some people setting NODE_TLS_REJECT_UNAUTHORIZED=0 and getting the problem "solved", but this just makes Node bypass the certificate verification. Not a good idea.

Would be great if this library can throw something in the logs when the TLS check fails. It would save a lot of time from this community figuring out how to solve this particular problem.

[okaufmann]

Thanks @leonelsanchesdasilva !

I had exactly the same problem. The API had to be called locally via HTTPS and since nuxt-auth cannot reload the user, it logs out and causes this behavior.

After adding NODE_TLS_REJECT_UNAUTHORIZED=0 to the .env file (@nuxt/dotenv needed) it worked again.

It also seems to make sense to enable axios debug logs. Add this to your nuxt.config.js

  /*
   ** Axios module configuration
   ** See https://axios.nuxtjs.org/options
   */
  axios: {
    debug: process.env.NODE_ENV && process.env.NODE_ENV === 'development',
    // See https://github.com/nuxt-community/axios-module#options
  },

Then you will get something like this:

[jasonlyu123]

Have the the same problem before. The auth module just catch all error in fetch user data request on server. This is not very dev friendly! Maybe a console error of this by default would make our life much more easier 👍.
It should log or throw every error other than a status code of 401. The annoy me every time when I just forget to start api server for debug because it catch all error and redirect to login even if auth api server is unreachable lol.

[brendanlong]

I had this problem and none of the above stuff applied to me (network logs showed that the user lookup was working). I fixed it by removing cookie: false from my nuxt.config.js. It's unclear to me why the cookie storage is required for this, since I would have expected local storage to work too.

[brendanlong]

Ah I see, cookie: false prevents server-side auth. The problem I'm running into is that the auth module doesn't work right in SPA mode.

[brendanlong]

Ah actually it does work in SPA mode. If I set mode: "spa" localStorage works correctly. I think the problem is that the middleware isn't getting called in universal mode, according to the docs:

In universal mode, middlewares will be called server-side once (on the first request to the Nuxt app or when page refreshes) and client-side when navigating to further routes. In SPA mode, middlewares will be called client-side on the first request and when navigating to further routes.

https://nuxtjs.org/guide/routing#middleware

Which explains the behavior I was getting with localstorage mode, where I'd be redirected to /login on refresh, but if I click any link, I'm suddenly logged in (since the middleware triggered).

I'm new to Nuxt (and Vue) so I'm not sure what we're supposed to do with a middleware which needs to run on both the client and server side on initial load (since the server doesn't necesarily have access to the auth token).

EDIT: Seems like this is by design and just how Nuxt middleware works nuxt/nuxt#2653 If you want to only use local storage and not cookies, you need to render in SPA mode.

It's possible there's some sort of plugin version of this auth module that would work in universal mode without cookies but I'm still too new at this to really understand the difference. My app is going to use SPA mode anyway so it doesn't really matter to me.