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

之前在聊一个问题,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_publiccreated_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
? 关注 → 追更不迷路,干货永同步

? 若有槽点想输出:
? 评论区已铺好红毯,等你来战!


请使用浏览器的分享功能分享到微信等