聊聊dify权限验证的三种方案及实现

前端方案： 修改前端接口调用

我在浏览器检查模式下查看接口调用的时候，发现接口http://10.1.0.65:8001/console/api/apps?page=1&limit=30&name=&is_created_by_me=false 发现有个一个参数 is_created_by_me。

从字面上看，就是是否只查询自己的，既然怀疑了，那就动手试一下，我在dify中新添加一个账户。

进去以后能看到全部。

在Edge浏览器下，我右键1，编辑并重新发送2,我把参数值改为true3,通过4我们可以看到请求值已经改变了，通过5,可以看到返回的数据为空。

然后我又看了下其他的接口发现两个接口

• console/api/workspaces/current 返回值有一个normal的

• console/api/account/profile  返回的是个人信息角色

同时，在dify的工作室，我们通过标签查询

那我们可以怎么做？

• 修改前端调用，非管理员的，只能调用自己的
• 定制前端界面，可以通过角色控制和标签控制，比如我们建一个公共的标签，前端完全可以控制。

后端方案
 

通过tags_ids去查，总感觉别扭，数据少了还行，数据多了，在生产上就是找事。我就翻下dify的数据库。

连接dify的数据库

我们在部署dify的时候有个.env文件，这里有pg数据库的

使用Navicat Premium Lite连接数据库

在apps表中，我发有一个is_public和created_by

在dify的数据库里，我们可以很明显的看到一个apps表，打开表以后，我们可以看到两列is_public和created_by。

那代码里有没有使用呢？我们翻下代码。

不得不说dify的代码结构还是很规范的，根据接口console/api/apps，我们能很轻松的找到对应的接口实现，然后没有看到我关注的is_public字段。

我再翻下更新接口的代码，

在代码里并没有对is_public的操作。看来这个是商业版的功能或者是未来开放的功能。

前后端加上这个字段难度不大。

我们可以直接在这里根据用户的角色进行改造。在对应的表tenant_account_joins 可以设置新的角色，然后在代码里进行处理。

ChatFlow中添加权限
 

先画个简单的流程图。

新建一个Chatflow流程。

在chatFlow中有一个会话变量，用于存储会话中的上下文，也就是只要你一直在同一个会话，就可以保存着。

点击1,然后点击2，添加变量loginStatus 变量，1登录成功，0是未登录。

登录成功后我们进行变量赋值，把loginStatus变量设置为1。

整体流程如下：

• 我们可以把工作流发布成一个自定义工具
• 1用户输入问题
• 2先校验用户的状态，如果已经登录直接到7,未登录到3
• 3校验用户有无填写密钥，填写则到4
• 4通过http校验用户有无权限，有权限到5,无权限，直接回复
• 5有权限流转到6，
• 6设置变量loginStatus为1，然后流转到工作流