LightRAG/.prompts/001-multi-tenant-gap.md
Raphael MANSUY fe9b8ec02a
tests: stabilize integration tests + skip external services; fix multi-tenant API behavior and idempotency (#4)
* feat: Implement multi-tenant architecture with tenant and knowledge base models

- Added data models for tenants, knowledge bases, and related configurations.
- Introduced role and permission management for users in the multi-tenant system.
- Created a service layer for managing tenants and knowledge bases, including CRUD operations.
- Developed a tenant-aware instance manager for LightRAG with caching and isolation features.
- Added a migration script to transition existing workspace-based deployments to the new multi-tenant architecture.

* chore: ignore lightrag/api/webui/assets/ directory

* chore: stop tracking lightrag/api/webui/assets (ignore in .gitignore)

* feat: Initialize LightRAG Multi-Tenant Stack with PostgreSQL

- Added README.md for project overview, setup instructions, and architecture details.
- Created docker-compose.yml to define services: PostgreSQL, Redis, LightRAG API, and Web UI.
- Introduced env.example for environment variable configuration.
- Implemented init-postgres.sql for PostgreSQL schema initialization with multi-tenant support.
- Added reproduce_issue.py for testing default tenant access via API.

* feat: Enhance TenantSelector and update related components for improved multi-tenant support

* feat: Enhance testing capabilities and update documentation

- Updated Makefile to include new test commands for various modes (compatibility, isolation, multi-tenant, security, coverage, and dry-run).
- Modified API health check endpoint in Makefile to reflect new port configuration.
- Updated QUICK_START.md and README.md to reflect changes in service URLs and ports.
- Added environment variables for testing modes in env.example.
- Introduced run_all_tests.sh script to automate testing across different modes.
- Created conftest.py for pytest configuration, including database fixtures and mock services.
- Implemented database helper functions for streamlined database operations in tests.
- Added test collection hooks to skip tests based on the current MULTITENANT_MODE.

* feat: Implement multi-tenant support with demo mode enabled by default

- Added multi-tenant configuration to the environment and Docker setup.
- Created pre-configured demo tenants (acme-corp and techstart) for testing.
- Updated API endpoints to support tenant-specific data access.
- Enhanced Makefile commands for better service management and database operations.
- Introduced user-tenant membership system with role-based access control.
- Added comprehensive documentation for multi-tenant setup and usage.
- Fixed issues with document visibility in multi-tenant environments.
- Implemented necessary database migrations for user memberships and legacy support.

* feat(audit): Add final audit report for multi-tenant implementation

- Documented overall assessment, architecture overview, test results, security findings, and recommendations.
- Included detailed findings on critical security issues and architectural concerns.

fix(security): Implement security fixes based on audit findings

- Removed global RAG fallback and enforced strict tenant context.
- Configured super-admin access and required user authentication for tenant access.
- Cleared localStorage on logout and improved error handling in WebUI.

chore(logs): Create task logs for audit and security fixes implementation

- Documented actions, decisions, and next steps for both audit and security fixes.
- Summarized test results and remaining recommendations.

chore(scripts): Enhance development stack management scripts

- Added scripts for cleaning, starting, and stopping the development stack.
- Improved output messages and ensured graceful shutdown of services.

feat(starter): Initialize PostgreSQL with AGE extension support

- Created initialization scripts for PostgreSQL extensions including uuid-ossp, vector, and AGE.
- Ensured successful installation and verification of extensions.

* feat: Implement auto-select for first tenant and KB on initial load in WebUI

- Removed WEBUI_INITIAL_STATE_FIX.md as the issue is resolved.
- Added useTenantInitialization hook to automatically select the first available tenant and KB on app load.
- Integrated the new hook into the Root component of the WebUI.
- Updated RetrievalTesting component to ensure a KB is selected before allowing user interaction.
- Created end-to-end tests for multi-tenant isolation and real service interactions.
- Added scripts for starting, stopping, and cleaning the development stack.
- Enhanced API and tenant routes to support tenant-specific pipeline status initialization.
- Updated constants for backend URL to reflect the correct port.
- Improved error handling and logging in various components.

* feat: Add multi-tenant support with enhanced E2E testing scripts and client functionality

* update client

* Add integration and unit tests for multi-tenant API, models, security, and storage

- Implement integration tests for tenant and knowledge base management endpoints in `test_tenant_api_routes.py`.
- Create unit tests for tenant isolation, model validation, and role permissions in `test_tenant_models.py`.
- Add security tests to enforce role-based permissions and context validation in `test_tenant_security.py`.
- Develop tests for tenant-aware storage operations and context isolation in `test_tenant_storage_phase3.py`.

* feat(e2e): Implement OpenAI model support and database reset functionality

* Add comprehensive test suite for gpt-5-nano compatibility

- Introduced tests for parameter normalization, embeddings, and entity extraction.
- Implemented direct API testing for gpt-5-nano.
- Validated .env configuration loading and OpenAI API connectivity.
- Analyzed reasoning token overhead with various token limits.
- Documented test procedures and expected outcomes in README files.
- Ensured all tests pass for production readiness.

* kg(postgres_impl): ensure AGE extension is loaded in session and configure graph initialization

* dev: add hybrid dev helper scripts, Makefile, docker-compose.dev-db and local development docs

* feat(dev): add dev helper scripts and local development documentation for hybrid setup

* feat(multi-tenant): add detailed specifications and logs for multi-tenant improvements, including UX, backend handling, and ingestion pipeline

* feat(migration): add generated tenant/kb columns, indexes, triggers; drop unused tables; update schema and docs

* test(backward-compat): adapt tests to new StorageNameSpace/TenantService APIs (use concrete dummy storages)

* chore: multi-tenant and UX updates — docs, webui, storage, tenant service adjustments

* tests: stabilize integration tests + skip external services; fix multi-tenant API behavior and idempotency

- gpt5_nano_compatibility: add pytest-asyncio markers, skip when OPENAI key missing, prevent module-level asyncio.run collection, add conftest
- Ollama tests: add server availability check and skip markers; avoid pytest collection warnings by renaming helper classes
- Graph storage tests: rename interactive test functions to avoid pytest collection
- Document & Tenant routes: support external_ids for idempotency; ensure HTTPExceptions are re-raised
- LightRAG core: support external_ids in apipeline_enqueue_documents and idempotent logic
- Tests updated to match API changes (tenant routes & document routes)
- Add logs and scripts for inspection and audit
2025-12-04 16:04:21 +08:00

248 lines
No EOL
9.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

## Your Role
Your an expert in System Engineering and Cloud Architecture working for a large SaaS company that provides multi-tenant applications to various clients. You have been tasked with designing a solution to address the challenges of data isolation, security, and scalability in a multi-tenant environment.
## The state of the art solution
This the current best practice approach to designing a multi-tenant architecture that ensures data isolation, security, and scalability for FastAPI applications using PostgreSQL, Neo4j, MongoDB, and Redis as data stores.# Multi-Tenant REST API with FastAPI + PostgreSQL + Neo4j + MongoDB + Redis: The 2025 Battle-Tested Approach
Here is the **battle-tested, production-grade approach** used by top multi-tenant SaaS companies in 2025 (e.g., Vercel, Render, Supabase, PostHog, Clerk, Auth0-scale systems) when building a multi-tenant REST API with **FastAPI + PostgreSQL + Neo4j + MongoDB + Redis**.
### Core Principle: "Shared Everything + Strict Tenant Scoping"
The winning strategy is **single database/cluster per data store**, with **row-level / document-level tenant isolation** enforced automatically at the framework level — never trust application code alone.
### 1. Tenant Identification (The One True Way)
Use **subdomains only** (`app.tenant-slug.yourdomain.com`)
Combined with **JWT `tenant_id` claim** (validated on every request)
```python
# middleware/tenant.py
from fastapi import Request, HTTPException, Depends
from sqlalchemy import text
from redis.asyncio import Redis
import uuid
async def get_tenant_context(request: Request, redis: Redis = Depends(get_redis)):
host = request.headers.get("host", "")
subdomain = host.split(".")[0] if "." in host else None # or use X-Tenant-ID fallback
if not subdomain:
raise HTTPException(400, "Tenant not found")
# Resolve tenant_id from Redis (cached) or DB
cache_key = f"tenant:slug:{subdomain}"
tenant_id = await redis.get(cache_key)
if not tenant_id:
async with db_session() as session:
result = await session.execute(
text("SELECT id FROM tenants WHERE slug = :slug AND active = true"),
{"slug": subdomain}
)
row = result.fetchone()
if not row:
raise HTTPException(404, "Tenant not found")
tenant_id = str(row[0])
await redis.setex(cache_key, 3600, tenant_id) # cache 1h
request.state.tenant_id = uuid.UUID(tenant_id)
request.state.tenant_slug = subdomain
return request.state
```
Use this dependency **globally**:
```python
app = FastAPI(dependencies=[Depends(get_tenant_context)])
```
### 2. PostgreSQL Row-Level Security (RLS) + Tenant UUID PK
**This is the gold standard in 2025 SaaS**
```sql
-- Every table
CREATE TABLE projects (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL DEFAULT current_setting('app.tenant_id')::UUID,
name TEXT,
-- all other fields
);
-- Enable RLS
ALTER TABLE projects ENABLE ROW LEVEL SECURITY;
-- Policy: tenants can only see their rows
CREATE POLICY tenant_isolation ON projects
USING (tenant_id = current_setting('app.tenant_id')::UUID);
```
Set tenant context **per connection** using a Pydantic-aware SQLAlchemy engine:
```python
# db/postgres.py
from sqlalchemy.ext.asyncio import create_async_engine, AsyncSession
from sqlalchemy import event
import uuid
engine = create_async_engine(DATABASE_URL)
@event.listens_for(engine.sync_engine, "connect")
def set_tenant_id(dbapi_connection, connection_record):
tenant_id = request_state_tenant_id() # thread-local from FastAPI state
cursor = dbapi_connection.cursor()
cursor.execute(f"SET app.tenant_id = '{tenant_id}'")
async def get_db() -> AsyncSession:
async with AsyncSession(engine) as session:
yield session
```
Now **even raw SQL leaks are impossible** — PostgreSQL blocks cross-tenant data.
### 3. MongoDB Automatic Tenant Filtering with Beanie ODM (or Motor)
Use **Beanie** (Motor + Pydantic) with a base document:
```python
from beanie import Document, PydanticObjectId
from uuid import UUID
class TenantDocument(Document):
tenant_id: UUID
class Settings:
name = "collection_name"
use_state_management = True
@classmethod
def get_motor_collection(cls):
# Auto-inject tenant filter
collection = super().get_motor_collection()
tenant_id = get_current_tenant_id() # from FastAPI state
return collection.with_options(
# This doesn't exist natively → use a wrapper instead
)
```
Better: **Create a tenant-scoped repository pattern**
```python
class MongoTenantRepo:
def __init__(self, collection):
self.collection = collection
self.tenant_id = get_current_tenant_id()
async def find(self, filter: dict | None = None, **kwargs):
filter = filter or {}
filter["tenant_id"] = self.tenant_id
return await self.collection.find(filter, **kwargs).to_list()
```
Never call `collection.find()` directly — always go through tenant repo.
### 4. Neo4j Tenant Prefix + APOC + Parameterized Queries
Neo4j has no RLS → enforce with **prefix labels** or **tenant_id property + strict query wrapper**
Best 2025 approach:
```python
class Neo4jTenantSession:
def __init__(self, driver):
self.driver = driver
self.tenant_id = get_current_tenant_id()
async def run(self, cypher: str, **params):
# Force tenant scoping
if "WHERE" not in cypher.upper():
cypher = cypher.rstrip() + f" WHERE n.tenant_id = $tenant_id"
params["tenant_id"] = str(self.tenant_id)
async with self.driver.session() as session:
return await session.run(cypher, params)
```
Or use **label prefixing** for extreme isolation:
```cypher
CREATE (n:Tenant_{tenant_id}:User {id: $id})
```
### 5. Redis Key Prefixing + Lua Scripts for Atomicity
Always prefix keys:
```python
def redis_key(*parts):
tenant_id = get_current_tenant_id()
return f"tenant:{tenant_id}:" + ":".join(str(p) for p in parts)
# Usage
await redis.set(redis_key("session", user_id), data, ex=3600)
await redis.get(redis_key("rate_limit", ip))
```
Use **Redis modules** like RediSearch or RedisJSON with tenant prefix indexes.
### 6. FastAPI Dependency Injection The Magic Glue
```python
# dependencies.py
def get_tenant_db() -> AsyncSession:
# SQLAlchemy session with tenant context already set
...
def get_mongo_tenant_repo():
return MongoTenantRepo(get_db_collection())
def get_neo4j_tenant():
return Neo4jTenantSession(neo4j_driver)
def get_redis_tenant():
tenant_id = get_current_tenant_id()
# Optionally use Redis with namespace
return redis # keys are prefixed in app code
```
Now every route is automatically tenant-safe:
```python
@router.get("/projects")
async def list_projects(
db: AsyncSession = Depends(get_tenant_db), # RLS enforced
mongo: MongoTenantRepo = Depends(get_mongo_tenant_repo),
neo: Neo4jTenantSession = Depends(get_neo4j_tenant),
):
projects = await db.execute(select(Project)) # auto-filtered by RLS
...
```
### 7. Additional Winning Practices (2025 SaaS Standard)
| Feature | Implementation |
|----------------------------|---------------------------------------------|
| Tenant Creation | Async task + background provisioning |
| Schema Migrations | Alembic + `SEARCH_PATH` per tenant (or shared with RLS) |
| Background Jobs | Celery/RQ with tenant context propagation |
| Analytics | Separate ClickHouse per tenant or tenant_id column |
| Rate Limiting | Redis Sliding Window per tenant |
| Feature Flags | LaunchDarkly / Unleash with tenant context |
| Audit Logs | MongoDB (append-only) + tenant_id |
| Testing | Pytest + tenant fixtures |
### Summary: The 2025 Winning Stack
- **FastAPI** with global tenant dependency
- **PostgreSQL + RLS** (hard isolation)
- **MongoDB** with tenant repository wrapper
- **Neo4j** with tenant session wrapper or prefixed labels
- **Redis** with strict key prefixing
- **Subdomain → tenant_id resolution** cached in Redis
- **Zero trust**: never allow raw queries without tenant context
This exact pattern powers many $100M+ SaaS companies today. It scales to 100k+ tenants with near-zero cross-tenant risk.
## Your Task
Make a full audit of the implementation of multi-tenancy in my LightRAG project. Identify any gaps or weaknesses in the current approach compared to the battle-tested approach outlined above. Provide specific recommendations for improvements to ensure robust data isolation, security, and scalability across all data stores used (PostgreSQL, Neo4j, MongoDB, Redis).
And provide a clear, concise, actionable plan to address these gaps, including code snippets where applicable and link to code that needs to be modified.
The plan must delivered in a markdown format with proper sections and subsections in multiple documents in docs/action_plan
YOU MUST navigate the codebase to identify the relevant files and code snippets that need to be changed. And conduct a thorough analysis of the current multi-tenant implementation.