尧图网页设计 
big-AGI 部署认证指南HTTP Basic Auth 与云平台认证方案详解【免费下载链接】big-AGIAI suite powered by state-of-the-art models and providing advanced AI/AGI functions. Includes AI personas, AGI functions, world-class Beam multi-model chats, text-to-image, voice, response streaming, code highlighting and execution, PDF import, presets for developers, much more. Deploy on-prem or in the cloud.项目地址: https://gitcode.com/GitHub_Trending/bi/big-AGIbig-AGI 是一个开箱即用的 AI 套件但默认不内置任何用户认证机制——任何能访问其端口的人都可以直接使用应用。本文基于 docs/deploy-authentication.md 官方文档系统讲解三种为部署加锁的认证方案通过重命名仓库内置中间件并重新构建来启用 HTTP Basic Authentication借助 Cloudflare Access / Vercel 等云平台的原生认证能力免重建保护应用以及自定义认证的扩展思路。读完本文你将掌握如何为自托管或云端部署的 big-AGI 实例配置账号密码访问控制并理解其底层中间件的工作原理与安全边界。为什么 big-AGI 需要额外的认证层big-AGI 的设计目标之一是自带 API Key 的客户端应用用户通常在自己的浏览器中配置各家 LLM 的 API Key服务端本身并不维护用户体系。因此官方明确说明项目不包含内置认证参见 docs/deploy-authentication.md。这意味着当你把 big-AGI 部署到公网服务器、Docker 容器或云平台时服务默认是完全开放的。官方文档提供了三条加锁路径构建期集成在构建应用时启用内置的 HTTP Basic Authentication平台层认证利用云部署平台Cloudflare、Vercel 等提供的用户认证与访问控制功能自定义方案针对企业或白标场景自行开发认证逻辑。下面逐一展开其中 HTTP Basic Authentication 是仓库中唯一开箱即用的认证实现也是本文的核心。方案一启用内置的 HTTP Basic Authentication原理Next.js 中间件层拦截请求HTTP Basic Authentication 是 HTTP 协议自带的简单认证方式浏览器在访问受保护资源时会弹出用户名/密码输入框并将凭据以Base64编码放入Authorization请求头。big-AGI 的实现位于仓库根目录的 middleware_BASIC_AUTH.ts。这是一个标准的 Next.js 中间件其核心逻辑如下配置校验若HTTP_BASIC_AUTH_USERNAME或HTTP_BASIC_AUTH_PASSWORD未设置直接返回401并提示 Unauthorized/Unconfigured避免出现看似开启、实则裸奔的配置陷阱凭据校验解析请求头中的Basic base64将解码后的username:password与两个环境变量逐一比对任一不符即返回401未认证响应以401状态码配合WWW-Authenticate: Basic realmSecure big-AGI响应头通知浏览器弹出认证对话框匹配范围中间件的matcher覆盖根路径/、页面路由/(call|index|news|personas|link)(.*)以及全部/api(.*)接口同时刻意排除了_next静态资源等保证认证拦截覆盖业务入口而不过度影响静态资源加载。因此启用认证必须重新构建应用——默认的middleware.ts并不存在需要手动将认证中间件激活。操作步骤一克隆仓库并激活认证中间件首先克隆 big-AGI 仓库并进入目录git clone https://gitcode.com/GitHub_Trending/bi/big-AGI.git cd big-AGI然后将认证中间件重命名为 Next.js 约定的中间件文件名mv middleware_BASIC_AUTH.ts middleware.ts这是整个流程中最关键的一步Next.js 只会自动加载名为middleware.ts或middleware.js的文件默认仓库中该文件带有_BASIC_AUTH后缀正是为了在不需要认证时静默停用此功能。文件头部的注释也明确指向 docs/deploy-authentication.md 作为启用指南。操作步骤二配置认证环境变量认证所需的用户名与密码通过两个后端环境变量注入官方示例见 docs/environment-variables.mdHTTP_BASIC_AUTH_USERNAMEyour username HTTP_BASIC_AUTH_PASSWORDyour password这两个变量在服务端环境校验文件 src/server/env.server.ts 中被声明为可选的字符串类型——即不设置不会报错但结合上述中间件逻辑可知一旦启用中间件而漏配变量应用会对所有请求返回 401等于把自己锁在门外。因此配置时应二者同时设置缺一不可。从配置层级看这两个变量属于后端变量既可以在运行next start前的 shell 环境或.env文件中设置也可以在 Docker 启动容器时通过-e或--env-file注入它们会在运行时被中间件读取无需在构建期固化。操作步骤三重新构建并启动由于中间件在构建时被纳入应用必须完成一次完整的生产构建。官方推荐两条构建路径路径 A本地生产构建详见 docs/installation.md 中的 Local Production build 一节npm install npm run build npx next start --port 3000路径 BDocker 构建与运行详见 docs/deploy-docker.mddocker build -t big-agi . docker run -d -p 3000:3000 big-agi采用 Docker 方式时认证变量应在运行容器时注入例如docker run -d -p 3000:3000 \ -e HTTP_BASIC_AUTH_USERNAMEadmin \ -e HTTP_BASIC_AUTH_PASSWORDyour-strong-password \ big-agi若使用 docker-compose可以在environment:小节下声明这两个变量或在启动命令中使用--env-file指向包含认证配置的文件。启动完成后浏览器访问http://localhost:3000会立即弹出 Basic Auth 对话框curl也可直接验证# 未携带凭据应返回 401 curl -i http://localhost:3000 # 携带凭据应返回 200 与应用内容 curl -i -u admin:your-strong-password http://localhost:3000同理在 Kubernetes 部署中参见 docs/deploy-k8s.md可将HTTP_BASIC_AUTH_USERNAME与HTTP_BASIC_AUTH_PASSWORD写入 Secret参考 docs/k8s/env-secret.yaml并在 docs/k8s/big-agi-deployment.yaml 的容器环境变量中引用随后正常执行kubectl apply即可。安全边界与使用建议从 middleware_BASIC_AUTH.ts 的实现可以明确以下几点部署时应格外注意HTTP Basic Auth 并不加密凭据Base64只是编码而非加密凭据在传输中可被截获还原。必须在 HTTPS/TLS 之后使用否则明文等效于裸奔它适合轻量防护而非多用户体系所有用户共享同一组用户名/密码无法区分身份、无法审计个人行为也不支持登出/会话管理中间件拦截了/api路由这保证了前端页面与后端接口统一受保护避免页面锁了、接口开着的常见疏漏参见matcher配置中的/api(.*)条目密码强度是唯一的防线Basic Auth 面对暴力破解的能力有限建议使用高熵长密码并结合反向代理层的限速、IP 白名单等措施加固。如需在反向代理Nginx、Caddy 等后部署可参考 docs/deploy-reverse-proxy.md在代理层实现认证同样可行此时应用本身无需启用中间件。方案二使用云平台的认证能力免重建如果你的 big-AGI 运行在托管云平台官方推荐优先利用平台自带的认证能力——无需修改代码、无需重新构建由平台在请求到达应用之前统一完成身份校验。官方文档列出了两个已验证的选项Cloudflare Access / Zero Trust在 Cloudflare 侧为部署配置 Access 策略可基于成员身份、邮箱域、一次一码One-time PIN等方式控制访问并支持与既有身份提供商IdP对接配合 Cloudflare Pages/Workers 部署时尤其顺手。Cloudflare Pages 的具体部署流程含构建命令与nodejs_compat兼容性标志等前置条件见 docs/deploy-cloudflare.md其 Access Policy 一节也演示了如何对预览域名与主域名启用访问策略。Vercel Authentication / Password ProtectionVercel 提供了部署级认证与密码保护两类机制。前者可结合团队/成员体系精细控制访问后者为整个部署设置统一访问密码适合快速上线场景。此外官方文档欢迎社区补充更多平台方案如 Heroku、AWS IAM、Google IAP 等。这类方案的核心优势是认证发生在平台边缘层与 big-AGI 应用解耦后续应用升级、重建镜像都不会影响认证策略同时天然具备审计日志、SSO 集成等企业级能力。方案三自定义认证方案当上述两条路径都无法满足需求例如需要多租户、细粒度权限、与自建用户系统打通时官方给出的第三条路是自行开发认证方案。结合仓库现状你可以从以下几个方向切入扩展中间件以 middleware_BASIC_AUTH.ts 为模板编写新的middleware.ts例如对接 OIDC/JWT 校验、会话 Cookie 等替换掉简单的 Basic Auth 逻辑在服务端路由层加认证big-AGI 的 tRPC 路由见 src/server/trpc/trpc.router-cloud.ts是后端能力的统一入口可在中间件层对api请求统一鉴权叠加第三方网关在反向代理或 API 网关层实现 SSO 登录页、令牌刷新等完整认证流程应用侧保持无状态。自定义方案没有现成代码可抄需要结合自身的身份源IdP与部署拓扑设计但其收益是可实现完全贴合业务的访问控制。如何选择三种方案对比与决策建议方案是否需重建应用用户体系实施成本适用场景HTTP Basic Authentication是重命名中间件 重新构建单组共享账号极低个人自托管、内网工具、快速上锁云平台认证Cloudflare / Vercel否平台成员/密码策略低云上部署、团队协作、SSO 需求自定义认证视实现而定完全自定义高企业白标、多租户、细粒度权限一个务实的组合是内网或小规模部署直接启用 HTTP Basic Auth务必置于 HTTPS 之后云上部署优先使用平台 Access/Password Protection 并配合反向代理加固需要完整用户体系时再投入自定义方案。无论选择哪条路径都建议在启用认证后立即用curl -i验证未授权请求确实返回401并用官方 docs/deploy-reverse-proxy.md 与 docs/environment-variables.md 两份文档交叉检查部署链路确保认证层覆盖了页面与 API 的全部入口。【免费下载链接】big-AGIAI suite powered by state-of-the-art models and providing advanced AI/AGI functions. Includes AI personas, AGI functions, world-class Beam multi-model chats, text-to-image, voice, response streaming, code highlighting and execution, PDF import, presets for developers, much more. Deploy on-prem or in the cloud.项目地址: https://gitcode.com/GitHub_Trending/bi/big-AGI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 big-AGI 部署认证指南：HTTP Basic Auth 与云平台认证方案详解
big-AGI 部署认证指南HTTP Basic Auth 与云平台认证方案详解【免费下载链接】big-AGIAI suite powered by state-of-the-art models and providing advanced AI/AGI functions. Includes AI personas, AGI functions, world-class Beam multi-model chats, text-to-image, voice, response streaming, code highlighting and execution, PDF import, presets for developers, much more. Deploy on-prem or in the cloud.项目地址: https://gitcode.com/GitHub_Trending/bi/big-AGIbig-AGI 是一个开箱即用的 AI 套件但默认不内置任何用户认证机制——任何能访问其端口的人都可以直接使用应用。本文基于 docs/deploy-authentication.md 官方文档系统讲解三种为部署加锁的认证方案通过重命名仓库内置中间件并重新构建来启用 HTTP Basic Authentication借助 Cloudflare Access / Vercel 等云平台的原生认证能力免重建保护应用以及自定义认证的扩展思路。读完本文你将掌握如何为自托管或云端部署的 big-AGI 实例配置账号密码访问控制并理解其底层中间件的工作原理与安全边界。为什么 big-AGI 需要额外的认证层big-AGI 的设计目标之一是自带 API Key 的客户端应用用户通常在自己的浏览器中配置各家 LLM 的 API Key服务端本身并不维护用户体系。因此官方明确说明项目不包含内置认证参见 docs/deploy-authentication.md。这意味着当你把 big-AGI 部署到公网服务器、Docker 容器或云平台时服务默认是完全开放的。官方文档提供了三条加锁路径构建期集成在构建应用时启用内置的 HTTP Basic Authentication平台层认证利用云部署平台Cloudflare、Vercel 等提供的用户认证与访问控制功能自定义方案针对企业或白标场景自行开发认证逻辑。下面逐一展开其中 HTTP Basic Authentication 是仓库中唯一开箱即用的认证实现也是本文的核心。方案一启用内置的 HTTP Basic Authentication原理Next.js 中间件层拦截请求HTTP Basic Authentication 是 HTTP 协议自带的简单认证方式浏览器在访问受保护资源时会弹出用户名/密码输入框并将凭据以Base64编码放入Authorization请求头。big-AGI 的实现位于仓库根目录的 middleware_BASIC_AUTH.ts。这是一个标准的 Next.js 中间件其核心逻辑如下配置校验若HTTP_BASIC_AUTH_USERNAME或HTTP_BASIC_AUTH_PASSWORD未设置直接返回401并提示 Unauthorized/Unconfigured避免出现看似开启、实则裸奔的配置陷阱凭据校验解析请求头中的Basic base64将解码后的username:password与两个环境变量逐一比对任一不符即返回401未认证响应以401状态码配合WWW-Authenticate: Basic realmSecure big-AGI响应头通知浏览器弹出认证对话框匹配范围中间件的matcher覆盖根路径/、页面路由/(call|index|news|personas|link)(.*)以及全部/api(.*)接口同时刻意排除了_next静态资源等保证认证拦截覆盖业务入口而不过度影响静态资源加载。因此启用认证必须重新构建应用——默认的middleware.ts并不存在需要手动将认证中间件激活。操作步骤一克隆仓库并激活认证中间件首先克隆 big-AGI 仓库并进入目录git clone https://gitcode.com/GitHub_Trending/bi/big-AGI.git cd big-AGI然后将认证中间件重命名为 Next.js 约定的中间件文件名mv middleware_BASIC_AUTH.ts middleware.ts这是整个流程中最关键的一步Next.js 只会自动加载名为middleware.ts或middleware.js的文件默认仓库中该文件带有_BASIC_AUTH后缀正是为了在不需要认证时静默停用此功能。文件头部的注释也明确指向 docs/deploy-authentication.md 作为启用指南。操作步骤二配置认证环境变量认证所需的用户名与密码通过两个后端环境变量注入官方示例见 docs/environment-variables.mdHTTP_BASIC_AUTH_USERNAMEyour username HTTP_BASIC_AUTH_PASSWORDyour password这两个变量在服务端环境校验文件 src/server/env.server.ts 中被声明为可选的字符串类型——即不设置不会报错但结合上述中间件逻辑可知一旦启用中间件而漏配变量应用会对所有请求返回 401等于把自己锁在门外。因此配置时应二者同时设置缺一不可。从配置层级看这两个变量属于后端变量既可以在运行next start前的 shell 环境或.env文件中设置也可以在 Docker 启动容器时通过-e或--env-file注入它们会在运行时被中间件读取无需在构建期固化。操作步骤三重新构建并启动由于中间件在构建时被纳入应用必须完成一次完整的生产构建。官方推荐两条构建路径路径 A本地生产构建详见 docs/installation.md 中的 Local Production build 一节npm install npm run build npx next start --port 3000路径 BDocker 构建与运行详见 docs/deploy-docker.mddocker build -t big-agi . docker run -d -p 3000:3000 big-agi采用 Docker 方式时认证变量应在运行容器时注入例如docker run -d -p 3000:3000 \ -e HTTP_BASIC_AUTH_USERNAMEadmin \ -e HTTP_BASIC_AUTH_PASSWORDyour-strong-password \ big-agi若使用 docker-compose可以在environment:小节下声明这两个变量或在启动命令中使用--env-file指向包含认证配置的文件。启动完成后浏览器访问http://localhost:3000会立即弹出 Basic Auth 对话框curl也可直接验证# 未携带凭据应返回 401 curl -i http://localhost:3000 # 携带凭据应返回 200 与应用内容 curl -i -u admin:your-strong-password http://localhost:3000同理在 Kubernetes 部署中参见 docs/deploy-k8s.md可将HTTP_BASIC_AUTH_USERNAME与HTTP_BASIC_AUTH_PASSWORD写入 Secret参考 docs/k8s/env-secret.yaml并在 docs/k8s/big-agi-deployment.yaml 的容器环境变量中引用随后正常执行kubectl apply即可。安全边界与使用建议从 middleware_BASIC_AUTH.ts 的实现可以明确以下几点部署时应格外注意HTTP Basic Auth 并不加密凭据Base64只是编码而非加密凭据在传输中可被截获还原。必须在 HTTPS/TLS 之后使用否则明文等效于裸奔它适合轻量防护而非多用户体系所有用户共享同一组用户名/密码无法区分身份、无法审计个人行为也不支持登出/会话管理中间件拦截了/api路由这保证了前端页面与后端接口统一受保护避免页面锁了、接口开着的常见疏漏参见matcher配置中的/api(.*)条目密码强度是唯一的防线Basic Auth 面对暴力破解的能力有限建议使用高熵长密码并结合反向代理层的限速、IP 白名单等措施加固。如需在反向代理Nginx、Caddy 等后部署可参考 docs/deploy-reverse-proxy.md在代理层实现认证同样可行此时应用本身无需启用中间件。方案二使用云平台的认证能力免重建如果你的 big-AGI 运行在托管云平台官方推荐优先利用平台自带的认证能力——无需修改代码、无需重新构建由平台在请求到达应用之前统一完成身份校验。官方文档列出了两个已验证的选项Cloudflare Access / Zero Trust在 Cloudflare 侧为部署配置 Access 策略可基于成员身份、邮箱域、一次一码One-time PIN等方式控制访问并支持与既有身份提供商IdP对接配合 Cloudflare Pages/Workers 部署时尤其顺手。Cloudflare Pages 的具体部署流程含构建命令与nodejs_compat兼容性标志等前置条件见 docs/deploy-cloudflare.md其 Access Policy 一节也演示了如何对预览域名与主域名启用访问策略。Vercel Authentication / Password ProtectionVercel 提供了部署级认证与密码保护两类机制。前者可结合团队/成员体系精细控制访问后者为整个部署设置统一访问密码适合快速上线场景。此外官方文档欢迎社区补充更多平台方案如 Heroku、AWS IAM、Google IAP 等。这类方案的核心优势是认证发生在平台边缘层与 big-AGI 应用解耦后续应用升级、重建镜像都不会影响认证策略同时天然具备审计日志、SSO 集成等企业级能力。方案三自定义认证方案当上述两条路径都无法满足需求例如需要多租户、细粒度权限、与自建用户系统打通时官方给出的第三条路是自行开发认证方案。结合仓库现状你可以从以下几个方向切入扩展中间件以 middleware_BASIC_AUTH.ts 为模板编写新的middleware.ts例如对接 OIDC/JWT 校验、会话 Cookie 等替换掉简单的 Basic Auth 逻辑在服务端路由层加认证big-AGI 的 tRPC 路由见 src/server/trpc/trpc.router-cloud.ts是后端能力的统一入口可在中间件层对api请求统一鉴权叠加第三方网关在反向代理或 API 网关层实现 SSO 登录页、令牌刷新等完整认证流程应用侧保持无状态。自定义方案没有现成代码可抄需要结合自身的身份源IdP与部署拓扑设计但其收益是可实现完全贴合业务的访问控制。如何选择三种方案对比与决策建议方案是否需重建应用用户体系实施成本适用场景HTTP Basic Authentication是重命名中间件 重新构建单组共享账号极低个人自托管、内网工具、快速上锁云平台认证Cloudflare / Vercel否平台成员/密码策略低云上部署、团队协作、SSO 需求自定义认证视实现而定完全自定义高企业白标、多租户、细粒度权限一个务实的组合是内网或小规模部署直接启用 HTTP Basic Auth务必置于 HTTPS 之后云上部署优先使用平台 Access/Password Protection 并配合反向代理加固需要完整用户体系时再投入自定义方案。无论选择哪条路径都建议在启用认证后立即用curl -i验证未授权请求确实返回401并用官方 docs/deploy-reverse-proxy.md 与 docs/environment-variables.md 两份文档交叉检查部署链路确保认证层覆盖了页面与 API 的全部入口。【免费下载链接】big-AGIAI suite powered by state-of-the-art models and providing advanced AI/AGI functions. Includes AI personas, AGI functions, world-class Beam multi-model chats, text-to-image, voice, response streaming, code highlighting and execution, PDF import, presets for developers, much more. Deploy on-prem or in the cloud.项目地址: https://gitcode.com/GitHub_Trending/bi/big-AGI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考