关于前端:这样在管理后台里实现-403-页面实在是太优雅了

403 页面通常示意无权限拜访，与 404 页面代表着不同含意。而大部分治理后盾框架仅提供了 404 页面的反对，但却疏忽了对 403 页面的解决，有的框架尽管也有对 403 页面的解决，但解决成果却不尽人意。

那怎么样的 403 页面才是即好用，又优雅呢？

不解决的后果就是无拜访权限的页面大概率会进入 404 页面的逻辑。

因为这类框架通常在路由注册前就把无拜访权限的路由间接剔除了，所以当用户拜访了一个无拜访权限的路由，对系统来说，它就是一个不存在的路由，从而进入到 404 页面。

那弊病是什么呢？那就是用户没方法辨别他想拜访的这个页面，到底是因为权限不够，还是地址谬误，会给用户造成肯定的应用困惑。

稍稍解决的形式和第一种思路不太一样，这类框架在路由注册前并不会对路由数据做解决，而是在路由导航守卫里去判断是否有权限拜访路由，如果没有权限则进入到事后注册好的 403 页面地址。

这种计划的劣势在于它辨别了 404 和 403 页面，因为即使是无拜访权限的路由，也是实在注册到了路由实例上，只是在拜访时做了鉴权和重定向。

那弊病又是什么呢？那就是用户尽管晓得了以后页面无拜访权限，但却看不到页面的实在地址，因为曾经被重定向到 403 页面上了，用户体验略微欠缺了一点，就像下图这样：

先略微思考一下计划，首先方才第一种计划剔除无拜访权限的路由必定不行，无拜访权限的路由必须得注册，这样能力和 404 页面做出辨别；其次第二种计划在导航守卫里做重定向也不行，不能重定向，要保障路由地址还是原来的地址，但页面要展现 403 页面的内容。

于是，计划就进去了，那就是 在路由注册前，将无拜访权限的路由的 component 间接替换成 403 页面组件 不就能够了么。这么一来，路由还是那个路由，只是对应的页面组件不一样了，既辨别了 404 和 403 页面，还保留 403 页面的原始路由地址。

用代码来形容大抵就是：

// 原始路由数据
[
  {
    path: '/permission',
    component: () => import('@/layouts/index.vue'),
    children: [
      {
        path: 'index',
        component: () => import('@/views/list1.vue'),
        meta: {auth: 'admin' // 鉴权字段，如果为 admin 时则能够拜访}
      }
    ]
  }
]

// 假如用户权限为 test，解决过后的路由数据
[
  {
    path: '/permission',
    component: () => import('@/layouts/index.vue'),
    children: [
      {
        path: 'index',
        component: () => import('@/views/403.vue'), // 留神看这里，替换成了 403 页面组件
        meta: {auth: 'admin'}
      }
    ]
  }
]

实际效果就是这样：

能够看到，当账号从 admin 切换到 test 后，因为 test 账号不具备拜访权限，所以页面显示为 403 页面，与此同时，页面的 URL 地址仍旧还是原始的地址，达到了预期的成果。

当然没有，因为 404 页面是通过以下形式做的兜底解决：

{path: '/:all(.*)*',
  component: () => import('@/views/404.vue')
}

因为它并不是一个多级路由的构造，这就导致 404 页面和 403 页面的展现有一点差异，404 页面是整页显示，403 页面是部分显示：

而我心愿是能和 404 页面保持一致，也就是让 403 页面也进行整屏显示。

解决起来也不简单，无非是在路由注册前，将无拜访权限的多级路由转成一级路由就能够啦，当然处理过程会应用到递归，以及须要将多级路由的 path 进行合并，从代码来形容大抵就是这样：

// 原始路由数据
[
  {
    path: '/permission',
    component: () => import('@/layouts/index.vue'),
    children: [
      {
        path: 'index',
        component: () => import('@/views/list1.vue'),
        meta: {auth: 'admin' // 鉴权字段，如果为 admin 时则能够拜访}
      }
    ]
  }
]

// 假如用户权限为 test，解决过后的路由数据
[
  {
    path: '/permission/index', // 注册看这里，将多级路由的 path 合并成一级
    component: () => import('@/layouts/403.vue'),
    meta: {auth: 'admin'}
  }
]

最终成果如下：

403 页面是个重要水平并不那么高的性能，对于个别框架来说，文章一开始提到了两个计划都能够做到「让权限有余的用户禁止拜访页面」的需要。

而我的计划则是在满足应用需要的前提下，尽可能优化用户体验，尽管没有提供理论的代码，但置信看到这的大家应该都能了解，能够在业务中去自行实际下。

至于优雅么？至多目前我感觉在同类产品里，还是挺优雅的😌

我在钻研下面第 2 个计划示例图里的那个框架时发现，它切换账号时不会刷新页面，体验还挺丝滑的。

当然这得益于它所选的计划，因为路由不须要随着用户权限或账号的变动而变动，所以也就不须要通过刷新页面或者从新登录的形式去更新路由。

或者我还能再优化优化，让这个计划再优雅一点？如果你有好的倡议，也能够在上面留言探讨下。

如果你对文章中我的这款 Fantastic-admin 框架感兴趣，能够点这里理解一下，这是一款『 开箱即用，能为你提供舒服开发体验 』的管理系统框架。

同时文章中我的计划也曾经集成进了框架中，想理解理论代码是如何实现的，也能够通过浏览源码理解。

以下是我往期写的一些对于治理后盾的文章，感兴趣能够持续浏览：

《如何做好一款治理后盾框架》
《我是如何设计后盾框架里那些精益求精的动画成果》
《一劳永逸，解决基于 keep-alive 的后盾多级路由缓存问题》
《在后盾框架同质化的明天，我是如何思考并做出差异化的》
《神奇！这款 Vue 后盾框架竟然不必手动配置路由》

关于前端:这样在管理后台里实现-403-页面实在是太优雅了

前言

其余框架是怎么做的

1、齐全不解决

2、稍稍解决

我是怎么做的

这就够了么？

总结

其余

最初