cameleer/cameleer-saas
2
0
Fork 0
Code Issues 24 Pull Requests Actions Packages Projects Releases Wiki Activity

chore: rename cameleer3 to cameleer
Some checks failed
CI / build (push) Failing after 18s
Details
CI / docker (push) Has been skipped
Details

Browse Source 
Rename Java packages from net.siegeln.cameleer3 to net.siegeln.cameleer,
update all references in workflows, Docker configs, docs, and bootstrap.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
hsiegeln
2026-04-15 15:28:44 +02:00
parent 44a0e413e9
commit 63c194dab7
113 changed files with 6190 additions and 582 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
docs/superpowers/specs/2026-04-15-per-tenant-pg-isolation-design.md
View File

@@ -5,7 +5,7 @@
## Context
The cameleer3-server team introduced `currentSchema` and `ApplicationName` JDBC parameters (commit `7a63135`) to scope admin diagnostic queries to a single tenant's connections. Previously, all tenant servers shared one PostgreSQL user and connected to the `cameleer3` database without schema isolation — a tenant's server could theoretically see SQL text from other tenants via `pg_stat_activity`.
The cameleer-server team introduced `currentSchema` and `ApplicationName` JDBC parameters (commit `7a63135`) to scope admin diagnostic queries to a single tenant's connections. Previously, all tenant servers shared one PostgreSQL user and connected to the `cameleer` database without schema isolation — a tenant's server could theoretically see SQL text from other tenants via `pg_stat_activity`.
This spec adds per-tenant PostgreSQL users and schemas so each tenant server can only access its own data at the database level.
@@ -13,7 +13,7 @@ This spec adds per-tenant PostgreSQL users and schemas so each tenant server can
### Current State
- All tenant servers connect as the shared admin PG user to `cameleer3` database, `public` schema.
- All tenant servers connect as the shared admin PG user to `cameleer` database, `public` schema.
- No per-tenant schemas exist — the server's Flyway runs in `public`.
- `TenantDataCleanupService` already attempts `DROP SCHEMA tenant_<slug>` on delete (no-op today since schemas don't exist).
- Standalone mode sets `currentSchema=tenant_default` in the compose file and is unaffected by this change.
@@ -40,7 +40,7 @@ public class TenantDatabaseService {
### `createTenantDatabase(slug, password)`
Connects to `cameleer3` using the admin PG credentials from `ProvisioningProperties`. Executes:
Connects to `cameleer` using the admin PG credentials from `ProvisioningProperties`. Executes:
1. Validate slug against `^[a-z0-9-]+$` (reject unexpected characters).
2. `CREATE USER "tenant_<slug>" WITH PASSWORD '<password>'` (skip if user already exists — idempotent for re-provisioning).
@@ -90,7 +90,7 @@ The `ProvisionRequest` record gains `dbPassword` field.
**When `dbPassword` is present** (new tenants):
```
SPRING_DATASOURCE_URL=jdbc:postgresql://cameleer-postgres:5432/cameleer3?currentSchema=tenant_<slug>&ApplicationName=tenant_<slug>
SPRING_DATASOURCE_URL=jdbc:postgresql://cameleer-postgres:5432/cameleer?currentSchema=tenant_<slug>&ApplicationName=tenant_<slug>
SPRING_DATASOURCE_USERNAME=tenant_<slug>
SPRING_DATASOURCE_PASSWORD=<generated>
```