Gotify与Authelia集成方案详解

背景介绍

Gotify是一款轻量级的实时消息推送服务，而Authelia则是一个开源的认证和授权系统。在实际部署中，很多用户希望将Gotify部署在Authelia保护的反向代理后面，同时又能保持Gotify的核心功能正常使用。本文将详细介绍如何实现这一目标。

核心问题分析

当Gotify部署在Authelia保护的代理后面时，会遇到以下几个关键问题：

1. API调用被Authelia拦截：Gotify的API端点（如/message）需要绕过Authelia认证
2. 移动应用连接问题：Android/iOS应用需要访问/version等端点
3. 认证机制冲突：Gotify自身的认证与Authelia认证可能产生冲突

解决方案

方法一：精确控制API端点访问

通过Authelia的resources配置，可以精确控制哪些API端点允许匿名访问：

access_control:
  default_policy: deny
  rules:
    - domain:
      - gotify.example.com
      resources:
      - '^/message([/?].*)?$'
      - '^/version([/?].*)?$'
      - '^/stream([/?].*)?$'
      - '^/current([/?].*)?$'
      - '^/client([/?].*)?$'
      - '^/application([/?].*)?$'
      - '^/user([/?].*)?$'
      - '^/health([/?].*)?$'
      - '^/plugin([/?].*)?$'
      policy: bypass

这种方法的优点是安全性较高，只开放必要的API端点。缺点是当Gotify新增API端点时需要手动更新配置。

方法二：基于HTTP方法的访问控制

另一种更宽松但更简单的方法是允许所有HTTP方法通过：

access_control:
  default_policy: deny
  rules:
    - domain:
      - gotify.example.com
      methods:
      - GET
      - POST
      - PUT
      - DELETE
      policy: bypass

这种方法配置简单，但安全控制粒度较粗，适合信任Gotify自身认证机制的环境。

移动应用支持

对于Gotify移动应用，需要特别注意以下几点：

1. 确保/version端点可访问
2. 静态资源访问：如果应用图标不显示，需要额外开放/static路径
3. 认证流程：移动应用通常使用token认证，确保相关API端点可访问

最佳实践建议

1. 将Authelia的bypass规则放在规则列表顶部
2. 定期检查Gotify API文档，确保覆盖所有必要端点
3. 对于生产环境，建议使用方法一进行更精确的控制
4. 测试所有功能，包括消息推送、应用管理和移动端连接

常见问题解决

1. 图标不显示：添加/static到bypass规则
2. 401认证错误：检查反向代理中间件配置，确保没有额外的认证层
3. API调用失败：验证端点是否全部正确配置，特别注意POST请求

通过以上配置，用户可以在享受Authelia提供的安全保护的同时，完整使用Gotify的所有功能。这种集成方案既保证了安全性，又不牺牲功能性，是自托管环境中的理想选择。