社区版dify应用编排完成后，点击运行按钮，会发布成一个独立的可访问链接。通过该链接其他用户可直接访问编排好的Dify应用，这样能够极大的方便Dify应用的分享与访问，如下图所示：

    但是社区版Dify中发布页面是没有用户鉴权的，这就导致一旦这个链接分享出去，任何有Dify系统访问权限的用户都可以访问该应用。如果该应用（特指Dify编排发布的应用）中涉及到企业内部数据，那么就存在数据泄露的风险，那么有没有什么手段可以在发布页面中增加用户鉴权呢？上周尝试了几种方案，这里进行统一汇总说明。

方案一：通过增加输入变量+内部鉴权的方式

    在Dify应用编排时，可以在开始节点手动增加额外的变量输入，这里我们就可把用户名+密码作为开始节点的变量，然后在工作流内部再增加用户鉴权，如下图所示：

    其中开始节点配置如下：

    最终页面呈现的效果如下

    即在每轮新开对话之前，都需要用户输入用户名密码，只有内部鉴权通过之后，才能继续后续操作，从而能在一定程度上做到用户鉴权。

    但这个方案也存在两个弊端：

    1、如上图所示，输入密码不是隐藏的效果，而是直接明文展示的，存在安全风险；

    2、这个用户名及密码输入只能够针对单个会话，如果新开一个会话就需要重新输入用户名及密码，在操作使用上存在不方便。

方案二：利用表单提交的形式进行用户名及密码输入

    方案一中，密码是明文显示的，那么有没有方案可以将密码进行隐藏的，这里在网上找到一个方案，通过表单的形式进行内容提交，很巧妙，而且未来可以做的事情将不止用户名密码输入。整体工作流如下图所示：

    如果是第1轮用户输入，要求用户先通过表单填写用户名及密码，然后就可以对用户名及密码进行鉴权以及进行后续操作（图中没有体现）。

    这里用到一个模版转化的节点，其内容如下：

    即定义了一个基本的用户名及密码提交表单（这里将密码输入内容做了password属性声明），并将转化后结果直接推送给回复节点进行展示，Dify会将其转化成页面表单的内容。最终实现效果如下图所示：

    这里可以看到，比较尴尬的是，虽然在表单提交页面密码做了加密处理，但是Dify非常耿直的将表单提交内容进行了二次输入，最终实际我们还是没有达到密码加密的目的。同样，这个方案也存在每一个新的会话都需要进行一次重复输入的过程。不过，这种表单的应用后续可以用在做在线调差问卷，满意度打分等场景，后续具有很强的可扩展性。

方案三：Dify页面嵌入到业务系统中

    目前在Dify发布页面中没有找到比较好用的用户鉴权方案，最终我们采用的方案是将Dify发布页面嵌入到业务系统中，鉴权的事情交给业务系统来做，Dify还是专注于工作流编排的事情。当然，这里这里也不是单纯的页面嵌入，还是希望增加一些鉴权手段的。如下图工作流所示：

    这里我们同样在开始节点增加一个msg输入参数，配置如下：

    设置其属性为隐藏，即不需要用户在开始页面进行编辑输入，这个参数将由业务系统在访问Dify链接时进行传入，最终业务系统调用链接如下所示：

    传递的msg信息是当前业务系统对当前“登录用户名+当前日期”的RSA加密结果，Dify获取到该密文后，将首先进行RAS解密，然后再提取其中的用户名和当前日期，如果解密失败或者日期非当前日期，则均提示用户名校验失败，只有校验通过后才允许执行后续操作。如下图所示：

    至此，我们在不改变

Dify原有代码的前提下，初步实现了Dify发布页面的用户鉴权过程，且整个过程中用户无需进行额外的输入，执行过程较为流畅。

    这里其实还存在一个问题没有解决，后续需要进行进一步研究，这里进行记录：

    当前为了防止其他用户拿到RSA加密后的密文直接仿造请求链接访问Dify页面，我们在密文中增加了当前日期作为时效性控制，即如果解密后的日期非当前日期，则认为密文失效，同样鉴权失败，保证了即使其他用户拿到了加密后的密文也只能当天有效，后续就失效了。

    但是在Dify实际应用中发现，通过链接传递进来的msg信息仅对新开会话生效，历史会话中的msg参数是不会变化的，这就导致之前历史会话将无法再次使用（历史的会话中保存的msg数据已失效），这在一定程度上也带来了不便性，需要后续继续解决。