之前在聊一个问题,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
,然后流转到工作流7
后记
dify的代码很规范,对于经验丰富的开发者来说,没有文档也能快速入手 dify是很灵活的,社区的资源也很丰富
我使用的是 2025-02-21
从github上拉下来的代码不管是哪种方案,都需要一定的代码能力(悄悄的告你们,你们可以在方案三里建一个知识库,用来做校验。 )
?【三连好运 福利拉满】?
? 若本日推送有收获:
? 点赞 → 小手一抖,bug没有
? 在看 → 一点扩散,知识璀璨
? 收藏 → 代码永驻,防止迷路
? 分享 → 传递战友,功德+999
? 关注 → 追更不迷路,干货永同步
? 若有槽点想输出:
? 评论区已铺好红毯,等你来战!