前端方案： 修改前端接口调用
我在浏览器检查模式下查看接口调用的时候，发现接口http://10.1.0.65:8001/console/api/apps?page=1&limit=30&name=&is_created_by_me=false 发现有个一个参数 is_created_by_me。
从字面上看，就是是否只查询自己的，既然怀疑了，那就动手试一下，我在dify中新添加一个账户。
进去以后能看到全部。
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
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,未登录到33校验用户有无填写密钥，填写则到44通过http校验用户有无权限，有权限到5,无权限，直接回复5有权限流转到6，6设置变量loginStatus为1，然后流转到工作流
