安全架构
Exportelier 的安全模型建立在刻意拆分为两个应用的基础上，使得处理您问题数据的那个应用根本无法把数据发送到任何地方。
主应用：无 fetch，无 webtrigger
主应用在其 Forge manifest 中不声明任何外部 fetch，也不声明 webtrigger。PDF 完全在 Forge 上渲染，不使用无头浏览器，也不使用第三方服务器。这由 Atlassian 平台强制执行——这是架构保证，而不是政策承诺。
示意图：主应用（无出站流量，在 Forge 上渲染）与 Automation 应用（承载全部出站流量，被隔离）并列。
Automation 应用：隔离的出站流量
所有需要向外发送数据的功能——邮件、Slack 传入 webhook、Microsoft Teams Workflows 和 API——都位于独立的 Exportelier Automation 应用中。它承载全部出站流量，并具备 SSRF 防护和按服务商区分的机密 URL。
报告以执行导出的用户身份读取 Jira
报告执行的每一次 Jira 读取——列出已保存过滤器、
在预检中检查它们、在导出期间搜索它们——都以启动该操作的人的身份运行，
使用 Forge 的 asUser 身份。应用绝不会为了让排队中的导出成功而回退到自身的应用身份。
由此直接得出两个特性：
- Exportelier 中的站点管理员身份绝不会扩大 Jira 的可见范围。 管理员可以基于 自己能看到的过滤器构建报告；这不会为其他任何人授予对这些过滤器的访问权限。 如果某个数据源对执行导出的用户不可用，导出会失败并指明该数据源的名称， 而不是悄悄省略它。
- 绝不会存储查询，也绝不会根据您的文本拼接查询。 Exportelier 只保留
已保存过滤器的数字 id，并构建唯一一个严格为数字的谓词
filter = <id>。过滤器的 JQL 绝不会被读取、存储、记录或拼接， 因此不存在 JQL 注入面，也不会留下您查询的过期副本。
报告输出是临时的，下载后即被删除——参见 数据保留与 GDPR。
仪表板导入仅使用有文档记录的 API
仪表板导入完全通过 Atlassian 有文档记录的 Jira Cloud 仪表板 REST API 以执行导入的用户身份读取 Jira。它不会解析 Jira 网页、读取小工具 iframe、 截取屏幕截图、使用未公开文档的小工具偏好设置端点，也不会向 Forge 之外发送任何内容。 它不需要新增任何权限范围。
所读取的内容有意保持狭窄。小工具的配置值会依据按小工具划分的允许列表进行校验， 其大小上限远低于 Jira 自身的最大值，并且绝不会被记录、回显到错误信息中或写入审计事件。 过滤器的 JQL 绝不会被存储，即使某个小工具属性恰好包含它——导入生成的报告 保留的仍是与其他所有报告相同的数字过滤器 id。
其中涉及的一项操作 Get gadgets 被 Atlassian 标记为实验性。如果其响应不再与 Exportelier 针对真实 Jira 站点验证过的结果相符，导入路径会安全失败， 该功能会自行禁用，而不是基于误读的响应继续操作。已有的报告和导出不受影响。
审计事件会记录某条导入记录被检查或被删除。它们不包含小工具配置、不包含 JQL，也不包含问题数据。
为什么要拆分
如果您的策略禁止出站流量，您可以只安装主应用，从而获得没有任何内容离开 Atlassian 的硬性保证。需要投递功能的团队则可在知情的前提下加装 Automation 应用。