Implementation of vue-nuxt login authentication

introduce

Sorting out from mentor, making a summary and record

Link

https://auth.nuxtjs.org/api/options/#cookie

start

According to this document, after using @nuxt/auth, if the specified cookie: false is not displayed, the auth token will be stored in the cookie by default (the same is true for localstorage above)
So after the login interface is successful, the token will be stored in the form of auth._token.{provider}

The interface then takes the token from the cookie when requesting and sends it to the server as the interface credential.

Directory Structure

nuxt-dist is the file generated by webpack after each npm run dev or npm run build. The code in it can be regarded as the code we actually call at the end ( You can also modify and debug directly here, but it will be restored every time you re-run the project).

nuxt/auth has several schemes, for example, see this nuxt-dist/auth/schemes/local.js
There are several default options:

In the code we wrote, we used $auth.loginWith to call it, but in fact, loginWith ultimately calls login.

Then look at login, still in nuxt-dist/auth/schemes/local.js

nuxt-dist is the file generated by webpack after each npm run dev or npm run build. The code here can be regarded as the code we actually call at the end (you can also modify and debug it directly here, but it will be restored every time you re-run the project).
nuxt/auth has several schemes, for example, see this nuxt-dist/auth/schemes/local.js
There are several default options:

In the code we wrote, we used $auth.loginWith to call it, but in fact, loginWith ultimately calls login.

Then look at login, still in nuxt-dist/auth/schemes/local.js

this.name in the method is auth.strategy, which is local, local1, etc., and setStrategy() in the loginWith method above stores the auth.strategy information locally.
After success, tokenRequired defaults to true, and this.$auth.setToken is called. This method is in auth/schemes/auth.js

In this method

In this method, _key is assembled into ._token.local
This method is in auth/storage.js

Finally, this method calls the setCookie and serLocalStorage methods, stores the token in cookies and localstorage, and in setCookie, it is assembled again, adding cookies.prefix, which is auth by default.

Finally, after serialization, it is stored in the cookie.
Subsequently, axios directly takes it from the cookir and sends it with the request.

The entire login and authentication logic is basically like this.

Continue to go into the code

You can also configure multiple auth in nuxt.config.js: {strategies: {local

Login with WeChat, login with mobile number, login with account…

autoFetch

https://auth.nuxtjs.org/schemes/local
Fetch User
The uth module does not save information about the user, so there needs to be a way to get the user's information on e.g. a page reload. This is what the user endpoint is for. By default, this is also called after a successful login.

If user.autoFetch is true (default), endpoints.user sends a request immediately after a successful login. This endpoint should respond with JSON information for the specific user, assigned directly to the user property.

If you want to return the user information directly from the login session, set user.autoFetch to false, get the user information from the loginWith response, and pass it to setUser.

If you want to disable fetching user info entirely, set endpoints.user: false. This means the user info endpoint will never be called, but it also means the frontend knows nothing about the user; this.$auth.user will be {}.

ps: Since the interface needs to be replaced, user will automatically query, and the resulting error is not conducive to development. You can develop step by step through comments.

user: {
          autoFetch: false,
      }, 

Proxy configuration

The back-end interface of the project is based on the back-end low-code platform and Java interface. The names at the beginning of the interfaces are inconsistent, which can be handled through proxy, and cross-domain problems can also be solved.

	axios:
    // // baseURL:''
    proxy: true,
    prefix: '/',
    // credentials: false,
  },
   proxy: {
    '/biz': {
      target: 'http://xxlb/',
      pathRewrite: {
        '^/biz': '/biz/',
        changeOrigin: true // indicates whether it is cross-domain}
    },
    '/front': {
      target: 'http://xxlb/',
      pathRewrite: {
        '^/front': '/api/front',
        changeOrigin: true // indicates whether it is cross-domain}
    },

Request interception

	axios:
    // // baseURL:''
    proxy: true,
    prefix: '/',
    // credentials: false,
  },
   proxy: {
    '/biz': {
      target: 'http://xxlb/',
      pathRewrite: {
        '^/biz': '/biz/',
        changeOrigin: true // indicates whether it is cross-domain}
    },
    '/front': {
      target: 'http://xxlb/',
      pathRewrite: {
        '^/front': '/api/front',
        changeOrigin: true // indicates whether it is cross-domain}
    },

Handling interfaces with different prefixes

dev is used for local dev environment and cannot be used when deployed to the server.
You define a file, for example, called apiPrefix.js
In this file, you enumerate all the different interfaces and their prefix correspondence

const temp = {
api: ['/front/login', 'xxxxxx', 'xxxxx'],
api2: ['/test', 'xxxxxx'],
xxx: […]
}

This is equivalent to explicitly listing all the interfaces that need to use the prefix.
In the request interception of axios, according to the current request url, traverse the temp, determine which prefix it belongs to, and then assemble it.
For those requests that cannot be found in this temp, it is defaulted that no prefix is ​​needed and they can be ignored.

There are three benefits to this.
First, when you are maintaining, you can see at a glance which of your interfaces need to be prefixed with what kind of prefix. Second, when you initiate a request on the page, you can ensure the same calling method without having to change it on each URL.
Third, if the batch prefix is ​​modified later, it is easy for you to change it

If the production environment needs to call other server interfaces, there must be certain rules. If there are rules, we match the rules and then modify them.
Or part of an interface. In this case, we can also use a similar method as above, which is nothing more than

const temp = {
http://10.0.0.1/api: ['/front/login', 'xxxxxx', 'xxxxx'],
http://10.0.0.1/api2: ['/test', 'xxxxxx'],
http://10.0.0.1/xxx: […],
…
http://10.0.1.111/api: ['/sth/xxx']
}

Expand the prefix scope to include protocols and domain names

Dynamic routing configuration

https://www.nuxtjs.cn/guide/routing
You'll notice that the route path named users-id has an :id? parameter, indicating that the route is optional. If you want to make it a required route, you need to create an index.vue file in the users/_id directory.

nuxt-dist will automatically package and generate configuration

Redirection and auth permissions

https://auth.nuxtjs.org/guide/middleware
What is said here is that auth permission verification can be placed globally or in each route. Can also be turned off so that the middleware skips the check. Finally, it also introduces a usage, guest mode, which means that you don't have to log in to access this route, but if a logged-in user accesses this page, he will be redirected to the route set by redirect.home

Some scenarios require logging in to access, otherwise they will be redirected to the /login page. Now that we have done the processing, we can set auth: false to handle some pages so that they do not redirect to login. For example, a page I am encountering now generates a registration link through the background before registration. This page does not require token information.

This is the end of this article about the implementation of vue-nuxt login authentication. For more relevant vue-nuxt login authentication content, please search 123WORDPRESS.COM's previous articles or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!