前端方案: 修改前端接口调用
我在浏览器检查模式下查看接口调用的时候,发现接口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
,然后流转到工作流