fantastic-admin5.0发布，Vue3 + django重构（一）后端-优快云博客

本文链接：https://blog.youkuaiyun.com/tacity/article/details/145355066

说下写这个文章的背景信息

1、我是个后端开发者，主要语言是python，对前端了解不多，fantastic-admin的很多优点吸引了我，比如很多基础组件已经构建完毕，页面布局，主题风格丝滑切换，因此我算是深度绑定这个前端框架来构建我的应用；

2、后端我还是坚持选择django，可能大家会诟病这个框架比较重，反馈比较慢，不像flask之类的框架简单易用，从实际的使用中看，django我主要是用的是他的路由，安全模块，数据库管理模块，其中安全模块尤为重要，如果让我们手动在flask里加载各种安全组件，这个工作量远大于开发一个功能的消耗；

3、对于性能这块，搭建了一个小型的应用平台，1台2核4G的虚拟机，百十来人的单位用起来都没有太大问题，只要并发不太大就好，如果需要解决并发问题，可以通过缓存，如redis等来实现，也可以动态扩展；

综上所述，我选择的这个组合都比较成熟，安全有兜底，前端功能亮眼还不用花费过大的精力，数据库调用还有django的 ORM框架使用起来也比较方便，比传统写SQL 安全还快捷，易于理解，所以主技术栈就这么定下来了。

此文档主要讨论这套系统从0开始搭建的路由，和基本信息，对于复杂页面的构建，本文档就继续了，由于5.0是个比较大的更新，我个人也不是很了解，所以在这个文档的时候边调，边写，希望能对大家有所启迪。

django变化不大，甚至不用看文档就能搭建起来很是顺手

1、新建项目 all_in_one

创建一个应用crm，写入默认的数据库信息，然后启动程序，就这么简单，命令及截图如下：

pip3 install django                         # 安装django 我的版本是5.1.5
django-admin startproject all_in_one        # 新建项目 all_in_one
cd all_in_one                               # 进入 all_in_one 目录
python3 manage.py startapp crm              # 新建 crm 应用
python3 manage.py migrate                   # 写入默认的数据库，表信息
python3 manage.py runserver                 # 启动django

截图如下：

打开系统提示的链接 http://127.0.0.1:8000/，你应该会看到上面的图片，表示django已经按照默认启动了，这里我们可以在后台调整中文什么的内容，因为我们不准备用到django的默认页面展示功能，这里就不调整了。

2、修改django的默认路由设置

这部分，和上篇文章的内容一样，我只是从走了一遍流程，1分钟搞定，之前的代码有些地方略有瑕疵，这里给大家贴完整的代码

2-1、修改 /all_in_one/setting.py 文件，这样crm这个目录系统就能识别了，这个地方我还挺奇怪的，既然crm是通过命令创建的，完全可以自动添加到这个位置；

2-2、修改 /all_in_one/urls.py 文件，接管系统的路由设定

from django.contrib import admin
from django.urls import path, include

urlpatterns = [
    # path('admin/', admin.site.urls),
    path('crm/', include(('crm.urls', 'crm'), namespace='crm')),

]

这样就构建了一个crm的子路由，构建了 http://127.0.0.1:8000/crm/... 这样的链接

这时控制台的进程就会报错了，因为 crm 这个目录里并没有 urls.py 的文件，不用担心，在 crm 目录下创建 url.py 的文件，内容如下

from django.contrib import admin
from django.urls import path
from . import views

urlpatterns = [
    path('default', views.default_api, name='default'),

]

这时候控制台还在报错，因为 crm 目录下的views的文件并没有 default_api 这个函数，初学者这里会比较害怕，要连着改好几个文件，不用担心，django好像就是喜欢让用户手动创建文件

crm/views.py 文件内容如下

from django.shortcuts import render

# Create your views here.
from django.http import HttpRequest, JsonResponse

def default_api(request: HttpRequest) -> str :
 
	# 从POST请求的body中获取JSON数据
	response_data = {}
	response_data['status'] = 'OK'
	return JsonResponse(response_data, status=200)

这时在保存文件，你会发现控制台哪里没有报错了，打开链接 default_api ，你应该会看到下面的内容

这就是从后端生成的 json 数据，现在的应用已经基本转向了这种前后端分离的架构，所有从后端传到前端 json 数据是相当常用的数据传输方式，好了，现在由 url，view 构建的路由，视图体系就完成了，以后需要什么样的数据，直接在后端写url 和指定的视图就可以了，后端部分完毕！

我也大家在写完一个应用后，往往会从之前的应用进行修改套用，很少会重新开一个全新的项目，我写这个就是为了降低重新开项目的生疏感，现在好了1分钟搞定。

3、安装 CROS

跨域安全防护是前后端分离系统必须解决的问题，django系统的解决方案也很简单，只要安装包就可以了，因为早晚也得安装，所以现在就一起完成了吧。

pip3 install django-cors-headers

然后是在 django 的setting.py文件里修改设置，主要有以下几个设置：

1.增加应用

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'corsheaders',
    'all_in_one',
]
2、增加访问模式

CORS_ALLOWED_METHODS = [
    'DELETE',
    'GET',
    'OPTIONS',
    'PATCH',
    'POST',
    'PUT',
]
3、增加头信息，因为 fantastic-admin 需要用到token，所以在标准洗头信息里增加了token

CORS_ALLOWED_HEADERS = [
    'accept',
    'accept-encoding',
    'authorization',
    'content-type',
    'dnt',
    'origin',
    'token',
    'user-agent',
    'x-csrftoken',
    'x-requested-with',
]
4、增加前端访问许可

CORS_ALLOWED_ORIGINS = [
    "http://localhost:9000",
    "https://your-production-domain.com",
    # ... 其他允许的来源
]
5、增加前端可访问的主机名
ALLOWED_HOSTS = ['*']
6、修改调试模式，感觉这个选项对于前后端分离而言没有什么用处，而且后期上线还会被扫描出有安全漏洞，泄露服务器配置，所以就提前关闭了。
DEBUG = False

4、设置登录

登录是需要和fantastic-admin的接收代码做配合的，在5.0.0以后，这部分代码的注释很清晰，即返回的信息格式为：{ status: 1, error: '', data: {} }规则是当 status 为 1 时表示请求成功，为 0 时表示接口需要登录或者登录状态失效，需要重新登录

这里有一个坑，如果你仅仅返回标准信息，你会发现，系统没有跳转，也没有报错，就停在登录界面了，如果这时，你刷新了页面，则发现自己登录进去了，其实这里是你的回复信息缺少了内容

在fantastic-admin的帮助文档里你会看到，登录的时候需要给前端传递账号名称，token和头像三个信息，如果不传这3个信息，就会报错，页面也不跳转，标准格式应该是：

{ status: 1, error: '', data: {'account' : '系统管理员','account' : 'token','12345' : 'avatar':''} }

因为在fantastic-admin的 store/modules/user.ts 里的定义为：

async function login(data: {

account: string

password: string

}) {

const res = await apiUser.login(data)

storage.local.set('account', res.data.account)

storage.local.set('token', res.data.token)

storage.local.set('avatar', res.data.avatar)

account.value = res.data.account

token.value = res.data.token

avatar.value = res.data.avatar

}大家可以自行查看，到这里，基本的前后端接口的联调就基本完成了

fantastic-admin的5.0版本更新了很多内容，我降在后续的文章中进行阐述。

5、设置权限

fantastic-admin一个重要的场景就是权限，也只有配置好权限，后期才能真正用起来。

获取权限的方法，我一般是带着token到后台，后台通过token查询用户信息，然后获取权限列表，发给前端，这块坐着说需要我们自行修改，其实也很简单，我贴在下面

// 前端的代码，放在api/modules/user.ts里增加了data: { token: string} 这个变量

  // 获取权限
  permission: (data: {
    token: string
  }) => api.post('crm/permission', data, {
    // baseURL: '/mock/',
  }),

// 修改调用代码 store/modules.user.ts ,增加了{ token: token.value } 这个变量


    // 获取权限
    async function getPermissions() {
      const res = await apiUser.permission({ token: token.value })
      console.log(res)
      permissions.value = res.data.permissions
    }


// 后端代码，放在urls指定的views.py 里就好了
@csrf_exempt
def permission(request: HttpRequest) -> JsonResponse:

    # 忽略中间的验证过程
    
    response_data = {}
    response_data['status'] = '1'
    response_data['error'] = ''
    response_data['data'] = {}
    response_data['data']['permissions'] = ['user.admin']
    print(response_data)
    return JsonResponse(response_data, status=200)

这个过程就闭环了，在登录后，pinia 的 user里的permission 里就有了数据

这时候在两个路由里分别写上auth:['block'], 和auth:['user.admin'],那么一个路由能显示出来，一个显示不出来，证明权限获取成功。

后记

今天本来想重新弄一下后台，没想到遇到了一个可能是BUG的场景，这里记录一下，就是在setting.py，将默认的头文件增加了’token‘这个值，但是前端永远获取不到这个值，在浏览器的控制台报错，后台不支持 token，所以出发了CORS，阻断了获取 permission的请求。

我详细看了网络里的进度，发现在getpermission之前前端会先发个option是的请求获取后台能够接受的http头类型，这个类型就是在后台配置的CORS_ALLOW_HEADERS信息，因为是全新的环境，我就没有加别的内容，只增加了 token ，结果前端就是获取不到。

我问了AI，AI也是各种解释，就是没法解决问题，现在已经很少有AI无法解决的问题了。

于是我一气之下把之前项目中的所有headers都贴过去了，然后系统就神奇的自愈了，token也能够获取了，然后我一条一条的删新增的数据，发现即使把新增的都删掉，还是可以获取 token，于是我认为我碰到了BUG

这个BUG是，django会判断我们增加的headers，如果是标准的headers，系统就会随着内容的增减，更新一个缓存中的值，但是token并非标准头，是我们自定义的，系统不认为是标准头，就没有更新这个缓存，因为我只增加了这一个，所以缓存不变，前端获取不到。当我增加了别的头，系统检测到了，就更新了缓存，而后续我删除的都是标准头的一个类型，所以每次都能触发这个缓存的更新，大概就是这个意思。

我把我CORS_ALLOW_HEADERS 的内容贴出来供大家参考


CORS_ALLOW_HEADERS = [  
    'accept',  
    'accept-encoding',  
    'authorization',  
    'content-type',  
    'dnt',  
    'token',
    'origin',  
    'user-agent',  
    'x-csrftoken',  
    'x-requested-with',  
    'Access-Control-Allow-Origin',
    'sec-ch-ua',
    'sec-ch-ua-mobile',
    'sec-ch-ua-platform',
    # 其他你需要的头部  
]

好了，后端的内容就基本是这些了，今天重新弄了一次，把之前没有搞明白的也再次强化了下，fantastic-admin是个很好的前端框架，以后还会在这个基础上开发很多小产品，这里就打个广告，希望大家多多使用，促进开源社区的成长。

fantastic-admin 官网地址