@lobehub/lobehub 2.0.5 → 2.0.7

package/src/server/services/memory/userMemory/persona/service.ts

@@ -14,14 +14,33 @@ import { desc, eq } from 'drizzle-orm';
 
 import { UserMemoryModel } from '@/database/models/userMemory';
 import { UserPersonaModel } from '@/database/models/userMemory/persona';
+import { AiInfraRepos } from '@/database/repositories/aiInfra';
 import { LobeChatDatabase } from '@/database/type';
 import {
   MemoryAgentConfig,
   parseMemoryExtractionConfig,
 } from '@/server/globalConfig/parseMemoryExtractionConfig';
+import { KeyVaultsGateKeeper } from '@/server/modules/KeyVaultsEncrypt';
 import { LayersEnum } from '@/types/userMemory';
 import { trimBasedOnBatchProbe } from '@/utils/chunkers';
 
+const extractCredentialsFromVault = (
+  vault?: Record<string, unknown>,
+): { apiKey?: string; baseURL?: string } => {
+  if (!vault || typeof vault !== 'object') return {};
+
+  const apiKey =
+    'apiKey' in vault && typeof (vault as any).apiKey === 'string'
+      ? (vault as any).apiKey
+      : undefined;
+  const baseURL =
+    'baseURL' in vault && typeof (vault as any).baseURL === 'string'
+      ? (vault as any).baseURL
+      : undefined;
+
+  return { apiKey, baseURL };
+};
+
 interface UserPersonaAgentPayload {
   existingPersona?: string | null;
   language?: string;
@@ -45,7 +64,6 @@ interface UserPersonaAgentResult {
 export class UserPersonaService {
   private readonly preferredLanguage?: string;
   private readonly db: LobeChatDatabase;
-  private readonly runtime: ModelRuntime;
   private readonly agentConfig: MemoryAgentConfig;
 
   constructor(db: LobeChatDatabase) {
@@ -54,13 +72,36 @@ export class UserPersonaService {
     this.db = db;
     this.preferredLanguage = agentPersonaWriter.language;
     this.agentConfig = agentPersonaWriter;
-    this.runtime = ModelRuntime.initializeWithProvider(agentPersonaWriter.provider || 'openai', {
-      apiKey: agentPersonaWriter.apiKey,
-      baseURL: agentPersonaWriter.baseURL,
-    });
   }
 
   async composeWriting(payload: UserPersonaAgentPayload): Promise<UserPersonaAgentResult> {
+    const aiInfraRepos = new AiInfraRepos(this.db, payload.userId, {});
+    const runtimeState = await aiInfraRepos.getAiProviderRuntimeState(
+      KeyVaultsGateKeeper.getUserKeyVaults,
+    );
+
+    const providerId = await AiInfraRepos.tryMatchingProviderFrom(runtimeState, {
+      fallbackProvider: this.agentConfig.provider,
+      label: 'persona writer',
+      modelId: this.agentConfig.model,
+    });
+
+    const normalizedProvider = providerId.toLowerCase();
+    const { apiKey: vaultApiKey, baseURL: vaultBaseURL } = extractCredentialsFromVault(
+      runtimeState.runtimeConfig?.[normalizedProvider]?.keyVaults,
+    );
+
+    const useVaultCredential = !!vaultApiKey;
+    const apiKey = useVaultCredential ? vaultApiKey : this.agentConfig.apiKey;
+    const baseURL = useVaultCredential
+      ? vaultBaseURL || this.agentConfig.baseURL
+      : this.agentConfig.baseURL;
+
+    const runtime = await ModelRuntime.initializeWithProvider(normalizedProvider, {
+      apiKey,
+      baseURL,
+    });
+
     const personaModel = new UserPersonaModel(this.db, payload.userId);
     const lastDocument = await personaModel.getLatestPersonaDocument();
     const existingPersonaBaseline = payload.existingPersona ?? lastDocument?.persona;
@@ -68,7 +109,7 @@ export class UserPersonaService {
     const extractor = new UserPersonaExtractor({
       agent: 'user-persona',
       model: this.agentConfig.model,
-      modelRuntime: this.runtime,
+      modelRuntime: runtime,
     });
 
     const agentResult = await extractor.toolCall({

package/src/store/tool/slices/klavisStore/action.ts

@@ -210,10 +210,30 @@ export const createKlavisStoreSlice: StateCreator<
         instanceId: server.instanceId,
       });
 
+      // If server returned an auth error (during polling), silently return
+      // This happens when user is still in the process of authorizing
+      if (instanceStatus.error === 'AUTH_ERROR') {
+        set(
+          produce((draft: KlavisStoreState) => {
+            draft.loadingServerIds.delete(identifier);
+          }),
+          false,
+          n('refreshKlavisServerTools/pendingAuth'),
+        );
+        return;
+      }
+
       // If authentication failed, remove server and reset status
       if (!instanceStatus.isAuthenticated) {
         if (!instanceStatus.authNeeded) {
           // If no authentication needed, all is well
+          set(
+            produce((draft: KlavisStoreState) => {
+              draft.loadingServerIds.delete(identifier);
+            }),
+            false,
+            n('refreshKlavisServerTools/noAuthNeeded'),
+          );
           return;
         }
 

package/docs/self-hosting/server-database.mdx

@@ -1,157 +0,0 @@
----
-title: Deploying Server-Side Database for LobeHub
-description: Learn how to deploy LobeHub's server-side database using Postgres.
-tags:
-  - LobeHub
-  - Server-Side Database
-  - Postgres
-  - Deployment Guide
----
-
-# Deploying Server-Side Database
-
-LobeHub defaults to using a client-side database (IndexedDB) but also supports deploying a server-side database. LobeHub uses Postgres as the backend storage database.
-
-<Callout>
-  PostgreSQL is a powerful open-source relational database management system with high scalability
-  and standard SQL support. It provides rich data types, concurrency control, data integrity,
-  security, and programmability, making it suitable for complex applications and large-scale data
-  management.
-</Callout>
-
-This guide will introduce the process and principles of deploying the server-side database version of LobeHub on any platform from a framework perspective, so you can understand both the what and the why, and then deploy according to your specific needs.
-
-If you are already familiar with the complete principles, you can quickly get started by checking the deployment guides for each platform:
-
-<PlatformCards urlPrefix={'platform'} />
-
----
-
-For the server-side database version of LobeHub, a normal deployment process typically involves configuring three modules:
-
-1. Database configuration;
-2. Authentication service configuration;
-3. S3 storage service configuration.
-
-## Configure the Database
-
-Before deployment, make sure you have a Postgres database instance ready. You can choose from the following instances:
-
-- `A.` Use Serverless Postgres instances like Vercel/Neon;
-- `B.` Use self-deployed Postgres instances like Docker/Railway/Zeabur, collectively referred to as Node Postgres instances;
-
-<Callout>
-  There is a slight difference in the way they are configured in terms of environment variables.
-</Callout>
-
-Since we support file-based conversations/knowledge base conversations, we need to install the `pgvector` plugin for Postgres. This plugin provides vector search capabilities and is a key component for LobeHub to implement RAG.
-
-<Steps>
-  ### `NEXT_PUBLIC_SERVICE_MODE`
-
-  LobeHub supports both client-side and server-side databases, so we provide an environment variable for switching modes, which is `NEXT_PUBLIC_SERVICE_MODE`, with a default value of `client`.
-
-  For server-side database deployment scenarios, you need to set `NEXT_PUBLIC_SERVICE_MODE` to `server`.
-
-  <Callout type={'info'}>
-    In the official `lobehub` Docker image, this environment variable is already set to
-    `server` by default. Therefore, if you deploy using the Docker image, you do not need to configure
-    this environment variable again.
-  </Callout>
-
-  <Callout type={'tip'}>
-    Since environment variables starting with `NEXT_PUBLIC` take effect in the front-end code, they cannot be modified through container runtime injection. (Refer to the `next.js` documentation [Configuring: Environment Variables | Next.js (nextjs.org)](https://nextjs.org/docs/pages/building-your-application/configuring/environment-variables)). This is why we chose to create a separate DB version image.
-
-    If you need to modify variables with the `NEXT_PUBLIC` prefix in a Docker deployment, you must build the image yourself and inject your own `NEXT_PUBLIC` prefixed environment variables during the build.
-  </Callout>
-
-  ### `DATABASE_URL`
-
-  The core of configuring the database is to add the `DATABASE_URL` environment variable and fill in the Postgres database connection URL you have prepared. The typical format of the database connection URL is `postgres://username:password@host:port/database`.
-
-  <Callout type={'info'}>
-    If you want to enable SSL when connecting to the database, please refer to the
-    [documentation](https://stackoverflow.com/questions/14021998/using-psql-to-connect-to-postgresql-in-ssl-mode)
-    for setup instructions.
-  </Callout>
-
-  ### `DATABASE_DRIVER`
-
-  The `DATABASE_DRIVER` environment variable is used to distinguish between the two types of Postgres database instances, with values of `node` or `neon`.
-
-  To streamline deployment, we have set default values based on the characteristics of different platforms:
-
-  - On the Vercel platform, `DATABASE_DRIVER` defaults to `neon`;
-  - In our provided Docker image `lobehub`, `DATABASE_DRIVER` defaults to `node`.
-
-  Therefore, if you follow the standard deployment methods below, you do not need to manually configure the `DATABASE_DRIVER` environment variable:
-
-  - Vercel + Serverless Postgres
-  - Docker image + Node Postgres
-
-  ### `KEY_VAULTS_SECRET`
-
-  Considering that users will store sensitive information such as their API Key and baseURL in the database, we need a key to encrypt this information to prevent leakage in case of a database breach. Hence, the `KEY_VAULTS_SECRET` environment variable is used to encrypt sensitive information like user-stored apikeys.
-
-  <Callout type={'info'}>
-    You can generate a random 32-character string as the value of `KEY_VAULTS_SECRET` using `openssl
-                                                                                                                                                                                                  rand -base64 32`.
-  </Callout>
-</Steps>
-
-## Configuring Authentication Services
-
-In the server-side database mode, we need an authentication service to distinguish the identities of different users. There are many well-developed authentication solutions in the open-source community. We have integrated two different authentication services to meet the demands of different scenarios, one is Clerk, and the other is NextAuth.
-
-### Clerk
-
-[Clerk](https://clerk.com?utm_source=lobehub\&utm_medium=docs) is an authentication SaaS service that provides out-of-the-box authentication capabilities with high productization, low integration costs, and a great user experience. For those who offer SaaS products, Clerk is a good choice. Our official [LobeHub Cloud](https://LobeHub.com) uses Clerk as the authentication service.
-
-The integration of Clerk is relatively simple, requiring only the configuration of these environment variables:
-
-- `NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY` and `CLERK_SECRET_KEY`, which can be obtained from the Clerk console
-- `CLERK_WEBHOOK_SECRET`, which is generated by following these instructions: [Configure Clerk Authentication Service](/docs/self-hosting/advanced/auth/clerk#create-and-configure-webhook-in-clerk).
-
-<Callout type={'tip'}>
-  In Vercel deployment mode, we recommend using Clerk as the authentication service for a better
-  user experience.
-</Callout>
-
-However, this type of authentication relies on Clerk's official service, so there may be some limitations in certain scenarios:
-
-- For example, when using Clerk in China, it may be affected by the network environment.
-- Clerk is not suitable for scenarios that require complete private deployment.
-- It relies on `NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY`, which may not be readily usable with public Docker images.
-
-Therefore, for the above scenarios, we also provide NextAuth as an alternative solution.
-
-### NextAuth
-
-NextAuth is an open-source authentication library that supports multiple identity providers, including Auth0, Cognito, GitHub, Google, Facebook, Apple, Twitter, and more. NextAuth itself provides a complete authentication solution, including user registration, login, password recovery, integration with various identity providers, and more.
-
-For information on configuring NextAuth, you can refer to the [Authentication](/docs/self-hosting/advanced/authentication) documentation.
-
-<Callout type={'tip'}>
-  In the official Docker image `lobehub`, we recommend using NextAuth as the
-  authentication service.
-</Callout>
-
-## Configuring S3 Storage Service
-
-LobeHub has supported multimodal AI conversations since [a long time ago](https://x.com/lobehub/status/1724289575672291782), involving the function of uploading images to large models. In the client-side database solution, image files are stored as binary data directly in the browser's IndexedDB database. However, this solution is not feasible in the server-side database. Storing file-like data directly in Postgres will greatly waste valuable database storage space and slow down computational performance.
-
-The best practice in this area is to use a file storage service (S3) to store image files, which is also the storage solution relied upon for subsequent file uploads/knowledge base functions.
-
-<Callout type={'info'}>
-  In this documentation, S3 refers to a compatible S3 storage solution, which supports the Amazon S3
-  API-compatible object storage system. Common examples include Cloudflare R2, Alibaba Cloud OSS,
-  and self-deployable RustFS, ceph, all of which support the S3-compatible API.
-</Callout>
-
-For detailed configuration guidelines on S3, please refer to [S3 Object Storage](/docs/self-hosting/advanced/s3) for more information.
-
-## Getting Started with Deployment
-
-The above is a detailed explanation of configuring LobeHub with a server-side database. You can configure it according to your actual situation and then choose a deployment platform that suits you to start deployment:
-
-<PlatformCards urlPrefix={'platform'} />

package/docs/self-hosting/server-database.zh-CN.mdx

@@ -1,146 +0,0 @@
----
-title: 使用服务端数据库部署 - 配置数据库、身份验证服务和 S3 存储服务
-description: 本文将介绍服务端数据库版 LobeHub 的部署思路，解释如何配置数据库、身份验证服务和 S3 存储服务。
-tags:
-  - 服务端数据库
-  - Postgres
-  - S3存储服务
-  - 数据库配置
-  - 身份验证服务
-  - 环境变量配置
----
-
-# 使用服务端数据库部署
-
-LobeHub 默认使用客户端数据库（IndexedDB），同时也支持使用服务端数据库（下简称 DB 版）。LobeHub 采用了 Postgres 作为后端存储数据库。
-
-<Callout>
-  PostgreSQL 是一种强大的开源关系型数据库管理系统，具备高度扩展性和标准 SQL
-  支持。它提供了丰富的数据类型、并发处理、数据完整性、安全性及可编程性，适用于复杂应用和大规模数据管理。
-</Callout>
-
-本文将从框架角度介绍在任何一个平台中部署 DB 版 LobeHub 的流程和原理，让你知其然也知其所以然，最后可以根据自己的实际情况进行部署。
-
-如你已经熟悉完整原理，可以查看各个平台的部署指南快速开始：
-
-<PlatformCards urlPrefix={'platform'} />
-
----
-
-对于 LobeHub 的 DB 版，正常的部署流程都需要包含三个模块的配置：
-
-1. 数据库配置；
-2. 身份验证服务配置；
-3. S3 存储服务配置。
-
-## 配置数据库
-
-在部署之前，请确保你已经准备好 Postgres 数据库实例，你可以选择以下任一实例：
-
-- `A.` 使用 Vercel / Neon 等 Serverless Postgres 实例；
-- `B.` 使用 Docker / Railway / Zeabur 等自部署 Postgres 实例，下统称 Node Postgres 实例；
-
-<Callout>两者的配置方式在环境变量的取值上会略有一点区别，其他方面是一样的。</Callout>
-
-同时，由于我们支持了文件对话 / 知识库对话的能力，因此我们需要为 Postgres 安装 `pgvector` 插件，该插件提供了向量搜索的能力，是 LobeHub 实现 RAG 的重要构件之一。
-
-<Steps>
-  ### `NEXT_PUBLIC_SERVICE_MODE`
-
-  LobeHub 同时支持了客户端数据库和服务端数据库，因此我们提供了一个环境变量用于切换模式，这个变量为 `NEXT_PUBLIC_SERVICE_MODE`，该值默认为 `client`。
-
-  针对服务端数据库部署场景，你需要将 `NEXT_PUBLIC_SERVICE_MODE` 设置为 `server`。
-
-  <Callout type={'info'}>
-    在官方的 `lobehub` Docker 镜像中，已经默认将该环境变量设为 `server`，因此如果你使用
-    Docker 镜像部署，则无需再配置该环境变量。
-  </Callout>
-
-  <Callout type={'tip'}>
-    由于 `NEXT_PUBLIC` 开头的环境变量是在前端代码中生效的，而因此无法通过容器运行时注入进行修改。 （`next.js`的参考文档 [Configuring: Environment Variables | Next.js (nextjs.org)](https://nextjs.org/docs/pages/building-your-application/configuring/environment-variables) ) 这也是为什么我们选择再打一个 DB 版镜像的原因。
-
-    如果你需要在 Docker 部署中修改 `NEXT_PUBLIC` 前缀的变量，你必须自行构建镜像，在 build 时就把自己的 `NEXT_PUBLIC` 开头的环境变量打进去。
-  </Callout>
-
-  ### `DATABASE_URL`
-
-  配置数据库，核心是添加 `DATABASE_URL` 环境变量，将你准备好的 Postgres 数据库连接 URL 填入其中。数据库连接 URL 的通常格式为 `postgres://username:password@host:port/database`。
-
-  <Callout type={'info'}>
-    如果希望连接数据库时启用 SSL
-    ，请自行参考[文档](https://stackoverflow.com/questions/14021998/using-psql-to-connect-to-postgresql-in-ssl-mode)进行设置
-  </Callout>
-
-  ### `DATABASE_DRIVER`
-
-  `DATABASE_DRIVER` 环境变量用于区分两种 Postgres 数据库实例，`DATABASE_DRIVER` 的取值为 `node` 或 `neon`。
-
-  为提升部署便捷性，我们根据不同的平台特点设置了默认值：
-
-  - 在 Vercel 平台下，`DATABASE_DRIVER` 默认为 `neon`；
-  - 在我们提供的 Docker 镜像 `lobehub` 中，`DATABASE_DRIVER` 默认为 `node`。
-
-  因此如果你采用了以下标准的部署方式，你无需手动配置 `DATABASE_DRIVER` 环境变量：
-
-  - Vercel + Serverless Postgres
-  - Docker 镜像 + Node Postgres
-
-  ### `KEY_VAULTS_SECRET`
-
-  考虑到用户会存储自己的 API Key 和 baseURL 等敏感信息到数据库中，因此我们需要一个密钥来加密这些信息，避免数据库被爆破 / 脱库时这些关键信息被泄露。 因此有了 `KEY_VAULTS_SECRET` 环境变量，用于加密用户存储的 apikey 等敏感信息。
-
-  <Callout type={'info'}>
-    你可以使用 `openssl rand -base64 32` 生成一个随机的 32 位字符串作为 `KEY_VAULTS_SECRET` 的值。
-  </Callout>
-</Steps>
-
-## 配置身份验证服务
-
-在服务端数据库模式下，我们要为不同用户区分身份，因此需要一个身份验证服务。开源社区中已经存在较多完善的身份验证解决方案。我们在实现过程中集成了两种不同的身份验证服务，用于满足不同场景的诉求，一种是 Clerk ，另外一种是 NextAuth。
-
-### Clerk
-
-[Clerk](https://clerk.com?utm_source=lobehub\&utm_medium=docs) 是一个身份验证 SaaS 服务，提供了开箱即用的身份验证能力，产品化程度很高，集成成本较低，体验很好。对于提供 SaaS 化产品的诉求来说，Clerk 是一个不错的选择。我们官方提供的 [LobeHub Cloud](https://LobeHub.com)，就是使用了 Clerk 作为身份验证服务。
-
-Clerk 的集成也相对简单，只需要配置 `NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY` 、 `CLERK_SECRET_KEY` 和 `CLERK_WEBHOOK_SECRET` 环境变量即可，这三个环境变量可以在 Clerk 控制台中获取。
-
-<Callout type={'tip'}>
-  在 Vercel 部署模式下，我们推荐使用 Clerk 作为身份验证服务，可以获得更好的用户体验。
-</Callout>
-
-但是这种身份验证依赖了 Clerk 官方的服务，因此在一些场景下可能会有一些限制：
-
-- 比如在国内使用 Clerk 时，可能会受到网络环境的影响；
-- 需要完全私有化部署的场景下，Clerk 并不适用；
-- 必须依赖 `NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY`，对于公共 Docker 镜像无法开箱即用；
-
-因此针对上述场景，我们也提供了 NextAuth 作为备选方案。
-
-### NextAuth
-
-NextAuth 是一个开源的身份验证库，支持多种身份验证提供商，包括 Auth0、Cognito、GitHub、Google、Facebook、Apple、Twitter 等。NextAuth 本身提供了一套完整的身份验证解决方案，包括用户注册、登录、密码找回、多种身份验证提供商的集成等。
-
-关于 NextAuth 的配置，你可以参考 [身份验证](/zh/docs/self-hosting/advanced/authentication) 的文档获取更多信息。
-
-<Callout type={'tip'}>
-  在官方的 Docker 镜像 `lobehub` 中，我们推荐使用 NextAuth 作为身份验证服务。
-</Callout>
-
-## 配置 S3 存储服务
-
-LobeHub 在 [很早以前](https://x.com/lobehub/status/1724289575672291782) 就支持了多模态的 AI 会话，其中涉及到图片上传给大模型的功能。在客户端数据库方案中，图片文件直接以二进制数据存储在浏览器 IndexedDB 数据库，但在服务端数据库中这个方案并不可行。因为在 Postgres 中直接存储文件类二进制数据会大大浪费宝贵的数据库存储空间，并拖慢计算性能。
-
-这块最佳实践是使用文件存储服务（S3）来存储图片文件，同时 S3 也是文件上传 / 知识库功能所依赖的大容量静态文件存储方案。
-
-<Callout type={'info'}>
-  在本文档库中，S3 所指代的是指兼容 S3 存储方案，即支持 Amazon S3 API 的对象存储系统，常见例如
-  Cloudflare R2 、阿里云 OSS，可以自部署的 RustFS、ceph 等均支持 S3 兼容 API。
-</Callout>
-
-关于 S3 的详细配置指南，请参阅 [S3 对象存储](/zh/docs/self-hosting/advanced/s3) 了解详情。
-
-## 开始部署
-
-以上就是关于服务端数据库版 LobeHub 的配置详解，你可以根据自己的实际情况进行配置，然后选择适合自己的部署平台开始部署：
-
-<PlatformCards urlPrefix={'platform'} />