@lifeaitools/clauth 1.5.62 → 1.5.64
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.clauth-skill/SKILL.md +216 -216
- package/.clauth-skill/references/keys-guide.md +270 -270
- package/.clauth-skill/references/operator-guide.md +148 -148
- package/README.md +211 -211
- package/cli/api.js +121 -121
- package/cli/commands/install.js +404 -404
- package/cli/commands/scrub.js +231 -231
- package/cli/commands/serve.js +7576 -7526
- package/cli/commands/uninstall.js +164 -164
- package/cli/fingerprint.js +133 -133
- package/install.ps1 +109 -109
- package/install.sh +49 -49
- package/package.json +61 -61
- package/scripts/bin/bootstrap-linux +0 -0
- package/scripts/bin/bootstrap-macos +0 -0
- package/scripts/bootstrap.cjs +121 -121
- package/scripts/build.sh +45 -45
- package/supabase/functions/auth-vault/index.ts +255 -255
- package/supabase/migrations/001_clauth_schema.sql +103 -103
- package/supabase/migrations/002_vault_helpers.sql +90 -90
- package/supabase/migrations/20260317_lockout.sql +26 -26
|
@@ -1,148 +1,148 @@
|
|
|
1
|
-
# clauth Operator Guide
|
|
2
|
-
|
|
3
|
-
For teams deploying their own clauth instance from scratch.
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## What "Operator" Means
|
|
8
|
-
|
|
9
|
-
When you clone the clauth repo and run `clauth setup`, you're connecting to an existing vault. If you want to run your **own** vault (different Supabase project, your own team), you're the operator. This guide covers that.
|
|
10
|
-
|
|
11
|
-
---
|
|
12
|
-
|
|
13
|
-
## Step 1 — Supabase Project
|
|
14
|
-
|
|
15
|
-
You need a Supabase project. Create one at supabase.com if you don't have one.
|
|
16
|
-
|
|
17
|
-
Collect:
|
|
18
|
-
- Project URL: `https://<ref>.supabase.co`
|
|
19
|
-
- Anon key (public JWT)
|
|
20
|
-
- Service role key (admin JWT)
|
|
21
|
-
|
|
22
|
-
---
|
|
23
|
-
|
|
24
|
-
## Step 2 — Run Migrations
|
|
25
|
-
|
|
26
|
-
In Supabase SQL Editor (or via CLI), run both migration files in order:
|
|
27
|
-
|
|
28
|
-
1. `supabase/migrations/001_clauth_schema.sql`
|
|
29
|
-
2. `supabase/migrations/002_vault_helpers.sql`
|
|
30
|
-
|
|
31
|
-
Or via Supabase CLI:
|
|
32
|
-
```bash
|
|
33
|
-
supabase db push
|
|
34
|
-
```
|
|
35
|
-
|
|
36
|
-
This creates:
|
|
37
|
-
- `clauth_services` — service registry (12 services seeded)
|
|
38
|
-
- `clauth_machines` — machine fingerprint registry
|
|
39
|
-
- `clauth_audit` — all operations logged
|
|
40
|
-
- Vault helper RPCs (upsert/decrypt/delete/list)
|
|
41
|
-
|
|
42
|
-
---
|
|
43
|
-
|
|
44
|
-
## Step 3 — Deploy Edge Function
|
|
45
|
-
|
|
46
|
-
```bash
|
|
47
|
-
supabase functions deploy auth-vault --project-ref <your-ref>
|
|
48
|
-
```
|
|
49
|
-
|
|
50
|
-
Or deploy from the Supabase dashboard by uploading `supabase/functions/auth-vault/index.ts`.
|
|
51
|
-
|
|
52
|
-
The function automatically reads `CLAUTH_HMAC_SALT` and `CLAUTH_ADMIN_BOOTSTRAP_TOKEN` from Supabase Vault (or env vars if set).
|
|
53
|
-
|
|
54
|
-
---
|
|
55
|
-
|
|
56
|
-
## Step 4 — Generate and Store Secrets
|
|
57
|
-
|
|
58
|
-
Run this to generate a salt and bootstrap token:
|
|
59
|
-
```bash
|
|
60
|
-
node -e "const c=require('crypto'); console.log('SALT:', c.randomBytes(32).toString('hex')); console.log('BOOTSTRAP:', c.randomBytes(16).toString('hex'));"
|
|
61
|
-
```
|
|
62
|
-
|
|
63
|
-
Store them in Supabase Vault via SQL Editor:
|
|
64
|
-
```sql
|
|
65
|
-
select vault.create_secret('<your-salt>', 'CLAUTH_HMAC_SALT', 'clauth HMAC salt');
|
|
66
|
-
select vault.create_secret('<your-bootstrap>', 'CLAUTH_ADMIN_BOOTSTRAP_TOKEN', 'clauth bootstrap token');
|
|
67
|
-
```
|
|
68
|
-
|
|
69
|
-
Or via Supabase Dashboard → Vault → New Secret.
|
|
70
|
-
|
|
71
|
-
---
|
|
72
|
-
|
|
73
|
-
## Step 5 — Distribute to Team
|
|
74
|
-
|
|
75
|
-
Give team members:
|
|
76
|
-
1. Your Supabase project URL
|
|
77
|
-
2. Your Supabase anon key (public — safe to share)
|
|
78
|
-
3. The bootstrap token (treat as a shared secret — regenerate after everyone registers)
|
|
79
|
-
|
|
80
|
-
Each person runs:
|
|
81
|
-
```bash
|
|
82
|
-
git clone https://github.com/LIFEAI/clauth
|
|
83
|
-
cd clauth && .\install.ps1 # or bash install.sh
|
|
84
|
-
clauth setup
|
|
85
|
-
```
|
|
86
|
-
|
|
87
|
-
---
|
|
88
|
-
|
|
89
|
-
## Adding Team Members After Initial Setup
|
|
90
|
-
|
|
91
|
-
Once the bootstrap token has been used by the first person, you can either:
|
|
92
|
-
- Keep the same token for additional machines (it's reusable)
|
|
93
|
-
- Rotate it after everyone is registered:
|
|
94
|
-
|
|
95
|
-
```sql
|
|
96
|
-
-- Generate new one
|
|
97
|
-
select vault.create_secret('new-token-here', 'CLAUTH_ADMIN_BOOTSTRAP_TOKEN', 'rotated');
|
|
98
|
-
-- This overwrites the old one
|
|
99
|
-
```
|
|
100
|
-
|
|
101
|
-
---
|
|
102
|
-
|
|
103
|
-
## Viewing the Audit Log
|
|
104
|
-
|
|
105
|
-
```sql
|
|
106
|
-
select machine_hash, service_name, action, result, detail, created_at
|
|
107
|
-
from clauth_audit
|
|
108
|
-
order by created_at desc
|
|
109
|
-
limit 50;
|
|
110
|
-
```
|
|
111
|
-
|
|
112
|
-
---
|
|
113
|
-
|
|
114
|
-
## Disabling a Machine
|
|
115
|
-
|
|
116
|
-
If a machine is lost or stolen:
|
|
117
|
-
```sql
|
|
118
|
-
update clauth_machines set enabled = false where label = 'Dave-Desktop-Win11';
|
|
119
|
-
```
|
|
120
|
-
|
|
121
|
-
That machine's HMAC tokens will be rejected immediately.
|
|
122
|
-
|
|
123
|
-
---
|
|
124
|
-
|
|
125
|
-
## Rotating the HMAC Salt
|
|
126
|
-
|
|
127
|
-
If the salt is compromised, rotate it:
|
|
128
|
-
```sql
|
|
129
|
-
-- Find the existing secret ID
|
|
130
|
-
select id, name from vault.secrets where name = 'CLAUTH_HMAC_SALT';
|
|
131
|
-
|
|
132
|
-
-- Update it
|
|
133
|
-
select vault.update_secret('<id>', 'new-salt-here');
|
|
134
|
-
```
|
|
135
|
-
|
|
136
|
-
**Warning:** After rotating the salt, ALL existing machines will fail HMAC validation. Every machine needs to re-run `clauth setup` with the new bootstrap token.
|
|
137
|
-
|
|
138
|
-
---
|
|
139
|
-
|
|
140
|
-
## Project Identifiers (LIFEAI canonical)
|
|
141
|
-
|
|
142
|
-
| Item | Value |
|
|
143
|
-
|------|-------|
|
|
144
|
-
| Supabase project | `uvojezuorjgqzmhhgluu` |
|
|
145
|
-
| Supabase URL | `https://uvojezuorjgqzmhhgluu.supabase.co` |
|
|
146
|
-
| Edge Function | `auth-vault` (deployed, ACTIVE) |
|
|
147
|
-
| GitHub org | LIFEAI |
|
|
148
|
-
| Repo | https://github.com/LIFEAI/clauth |
|
|
1
|
+
# clauth Operator Guide
|
|
2
|
+
|
|
3
|
+
For teams deploying their own clauth instance from scratch.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## What "Operator" Means
|
|
8
|
+
|
|
9
|
+
When you clone the clauth repo and run `clauth setup`, you're connecting to an existing vault. If you want to run your **own** vault (different Supabase project, your own team), you're the operator. This guide covers that.
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## Step 1 — Supabase Project
|
|
14
|
+
|
|
15
|
+
You need a Supabase project. Create one at supabase.com if you don't have one.
|
|
16
|
+
|
|
17
|
+
Collect:
|
|
18
|
+
- Project URL: `https://<ref>.supabase.co`
|
|
19
|
+
- Anon key (public JWT)
|
|
20
|
+
- Service role key (admin JWT)
|
|
21
|
+
|
|
22
|
+
---
|
|
23
|
+
|
|
24
|
+
## Step 2 — Run Migrations
|
|
25
|
+
|
|
26
|
+
In Supabase SQL Editor (or via CLI), run both migration files in order:
|
|
27
|
+
|
|
28
|
+
1. `supabase/migrations/001_clauth_schema.sql`
|
|
29
|
+
2. `supabase/migrations/002_vault_helpers.sql`
|
|
30
|
+
|
|
31
|
+
Or via Supabase CLI:
|
|
32
|
+
```bash
|
|
33
|
+
supabase db push
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
This creates:
|
|
37
|
+
- `clauth_services` — service registry (12 services seeded)
|
|
38
|
+
- `clauth_machines` — machine fingerprint registry
|
|
39
|
+
- `clauth_audit` — all operations logged
|
|
40
|
+
- Vault helper RPCs (upsert/decrypt/delete/list)
|
|
41
|
+
|
|
42
|
+
---
|
|
43
|
+
|
|
44
|
+
## Step 3 — Deploy Edge Function
|
|
45
|
+
|
|
46
|
+
```bash
|
|
47
|
+
supabase functions deploy auth-vault --project-ref <your-ref>
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
Or deploy from the Supabase dashboard by uploading `supabase/functions/auth-vault/index.ts`.
|
|
51
|
+
|
|
52
|
+
The function automatically reads `CLAUTH_HMAC_SALT` and `CLAUTH_ADMIN_BOOTSTRAP_TOKEN` from Supabase Vault (or env vars if set).
|
|
53
|
+
|
|
54
|
+
---
|
|
55
|
+
|
|
56
|
+
## Step 4 — Generate and Store Secrets
|
|
57
|
+
|
|
58
|
+
Run this to generate a salt and bootstrap token:
|
|
59
|
+
```bash
|
|
60
|
+
node -e "const c=require('crypto'); console.log('SALT:', c.randomBytes(32).toString('hex')); console.log('BOOTSTRAP:', c.randomBytes(16).toString('hex'));"
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
Store them in Supabase Vault via SQL Editor:
|
|
64
|
+
```sql
|
|
65
|
+
select vault.create_secret('<your-salt>', 'CLAUTH_HMAC_SALT', 'clauth HMAC salt');
|
|
66
|
+
select vault.create_secret('<your-bootstrap>', 'CLAUTH_ADMIN_BOOTSTRAP_TOKEN', 'clauth bootstrap token');
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
Or via Supabase Dashboard → Vault → New Secret.
|
|
70
|
+
|
|
71
|
+
---
|
|
72
|
+
|
|
73
|
+
## Step 5 — Distribute to Team
|
|
74
|
+
|
|
75
|
+
Give team members:
|
|
76
|
+
1. Your Supabase project URL
|
|
77
|
+
2. Your Supabase anon key (public — safe to share)
|
|
78
|
+
3. The bootstrap token (treat as a shared secret — regenerate after everyone registers)
|
|
79
|
+
|
|
80
|
+
Each person runs:
|
|
81
|
+
```bash
|
|
82
|
+
git clone https://github.com/LIFEAI/clauth
|
|
83
|
+
cd clauth && .\install.ps1 # or bash install.sh
|
|
84
|
+
clauth setup
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
---
|
|
88
|
+
|
|
89
|
+
## Adding Team Members After Initial Setup
|
|
90
|
+
|
|
91
|
+
Once the bootstrap token has been used by the first person, you can either:
|
|
92
|
+
- Keep the same token for additional machines (it's reusable)
|
|
93
|
+
- Rotate it after everyone is registered:
|
|
94
|
+
|
|
95
|
+
```sql
|
|
96
|
+
-- Generate new one
|
|
97
|
+
select vault.create_secret('new-token-here', 'CLAUTH_ADMIN_BOOTSTRAP_TOKEN', 'rotated');
|
|
98
|
+
-- This overwrites the old one
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
---
|
|
102
|
+
|
|
103
|
+
## Viewing the Audit Log
|
|
104
|
+
|
|
105
|
+
```sql
|
|
106
|
+
select machine_hash, service_name, action, result, detail, created_at
|
|
107
|
+
from clauth_audit
|
|
108
|
+
order by created_at desc
|
|
109
|
+
limit 50;
|
|
110
|
+
```
|
|
111
|
+
|
|
112
|
+
---
|
|
113
|
+
|
|
114
|
+
## Disabling a Machine
|
|
115
|
+
|
|
116
|
+
If a machine is lost or stolen:
|
|
117
|
+
```sql
|
|
118
|
+
update clauth_machines set enabled = false where label = 'Dave-Desktop-Win11';
|
|
119
|
+
```
|
|
120
|
+
|
|
121
|
+
That machine's HMAC tokens will be rejected immediately.
|
|
122
|
+
|
|
123
|
+
---
|
|
124
|
+
|
|
125
|
+
## Rotating the HMAC Salt
|
|
126
|
+
|
|
127
|
+
If the salt is compromised, rotate it:
|
|
128
|
+
```sql
|
|
129
|
+
-- Find the existing secret ID
|
|
130
|
+
select id, name from vault.secrets where name = 'CLAUTH_HMAC_SALT';
|
|
131
|
+
|
|
132
|
+
-- Update it
|
|
133
|
+
select vault.update_secret('<id>', 'new-salt-here');
|
|
134
|
+
```
|
|
135
|
+
|
|
136
|
+
**Warning:** After rotating the salt, ALL existing machines will fail HMAC validation. Every machine needs to re-run `clauth setup` with the new bootstrap token.
|
|
137
|
+
|
|
138
|
+
---
|
|
139
|
+
|
|
140
|
+
## Project Identifiers (LIFEAI canonical)
|
|
141
|
+
|
|
142
|
+
| Item | Value |
|
|
143
|
+
|------|-------|
|
|
144
|
+
| Supabase project | `uvojezuorjgqzmhhgluu` |
|
|
145
|
+
| Supabase URL | `https://uvojezuorjgqzmhhgluu.supabase.co` |
|
|
146
|
+
| Edge Function | `auth-vault` (deployed, ACTIVE) |
|
|
147
|
+
| GitHub org | LIFEAI |
|
|
148
|
+
| Repo | https://github.com/LIFEAI/clauth |
|