html教程的内容windows优化大师提供的
概述
Ragflow-Plus v0.1.1 在经历一轮用户测试和反馈后，发现了一些问题，v0.1.2 版本进行一轮小更新，修复以下问题：
-
1.新建用户模型配置不全问题
-
2.用户为空时，添加用户异常问题
-
3.用户配置界面点击未刷新问题
-
4.管理员账号密码无法修改问题
-
5.前后端API调用访问不畅问题
Ragflow-Plus 仓库地址：
https://github.com/zstar1003/ragflow-plus
更新方式
如果尚未下载此仓库代码，推荐使用 git 的方式下载：
git clone https://github.com/zstar1003/ragflow-plus.git
如果已经使用 git 方式下载，可以在项目根路径下，执行此命令，拉取更新部分：
git pull
如果之前已使用过 docker 部署过Ragflow-Plus，升级新版本前，先手动删除zstar1003/ragflowplus-management-web和zstar1003/ragflowplus-management-server两个镜像，如果已有创建容器，需先删除对应镜像容器。
执行以下命令，重新拉取最新v0.1.2版本，并启动容器运行：
docker compose -f docker/docker-compose.yml up -d
以上是docker的部署方式，如需进行源码部署，可参考仓库的自述文件。
问题原因和解决思路
如果你想具体了解上述问题的造成原因和解决思路，可以继续接着看。
1. 新建用户模型配置不全问题
问题现象：如果用户配置了外载的模型，比如同时配置了chat和embedding模型，在新建用户时，只有chat模型配置成功，embedding模型配置失败，如下图所示：
问题原因：在新建用户时，只是复制tenant_llm表中最早记录的配置信息给新用户，当用户实际有多个模型配置时，只复制最早配置的一个，导致缺项。
解决方案：先查询user表中，最早用户的id，根据该id在tenant_llm表中复制所有该tenant_id的配置给新用户，具体修改项见management\server\services\users\service.py-create_user函数。
修改完成后，新用户可以复制老用户的所有模型设置。
2. 用户为空时，添加用户异常问题
问题现象：删除完所有用户后，在管理系统中新建用户，出现异常。
问题原因：这个功能起初是为了方便在已有用户的基础上，对新用户进行自动加团和模型配置。因此，新用户会自动查询最早用户的团队信息和模型配置。当用户表为空时，出现问题(找不到借鉴对象)。
解决方案：在新建用户时，新增一个判断，如果用户表为空，则不进行查询，而是形成一个空的模型默认配置。ragflow默认注册用户时，会塞入无用的qwen模型配置模板，此点同时对其进行优化，具体修改项见management\server\services\users\service.py-create_user函数。
3. 用户配置界面点击未刷新问题
问题现象：在管理系统中，添加完用户，切换到用户配置界面时，未显示更新，刷新后才显示。
问题原因：切换到用户配置菜单，未及时获取最新数据表信息。
解决方案：在用户配置页面(management\web\src\pages\user-config\index.vue)中，增加切换时获取数据表的事件响应。
onActivated(() => {getTableData()
})
4. 管理员账号密码无法修改问题
问题现象：在上一版本的管理系统中，管理员账号固化在代码中，也并未真正在后端对账号密码进行验证。
解决方案：在docker-compose.yml文件中，新增了后端账号密码的环境变量，现在可以在docker/.env文件中，修改以下三个可选项：
- MANAGEMENT_ADMIN_USERNAME：管理员账号
- MANAGEMENT_ADMIN_PASSWORD：管理员密码
- MANAGEMENT_JWT_SECRET：Token加密密钥
默认管理员账号为admin,默认密码为12345678。
如需修改，可以编辑完.env中的环境变量后，保存，重新启动容器：
docker compose -f docker/docker-compose.yml up -d
登录完一次后，会自动生成持续1小时的token，拥有token时，访问登录主页会自动进行登录跳转。
为防止token被破解和篡改，设定了MANAGEMENT_JWT_SECRET密钥进行加密，修改该值不影响正常功能。
5. 前后端API调用访问不畅问题
问题现象：将 ragflow-plus 用 docker 远程部署在服务器上时，登录时出现连接报错。
问题原因：管理系统前端默认通过 localhost 访问后端，远程访问时，会访问本地的localhost:5000端口，导致异常。
解决方案：其实之前的博文中已经包含一种解决方案，就是配置端口转发，将本地的5000端口映射到远程真正需要访问的5000端口。但是这样做并不优雅。
于是参考群友的改造方案，对其进行改良，首先将env.production的VITE_BASE_URL置空，然后配置前后端在同一网络环境，通过nginx.conf反向代理，将请求转发到后端端口：
location /api/ {# 将所有以/api/开头的请求转发到后端服务(backend容器的5000端口)proxy_pass http://backend:5000/api/;# 设置代理请求头proxy_set_header Host $host; # 保留原始请求的Host头# 传递客户端真实IPproxy_set_header X-Real-IP $remote_addr; # 记录客户端IP# 添加X-Forwarded-For头proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 代理链路追踪}
配置完之后，请求后端时，无需在用户侧配置端口转发。
