Turn on the Firebase project and prove remote identity against it for real
- Dominant language
- TypeScript
- Stars
- 1
- Forks
- 0
- Avg merge
- 1h 21m
- Merged PRs (30d)
- 41
Description
The code for #45 is built, verified and pushed on `bench/remote-identity-4b825ae1`. What is left is not code: nobody has ever actually signed in, because the Firebase project has nothing to sign in to.
Splitting it out because it is a different kind of task — three actions in a console that only the developer can take, and then the live checks that a green test suite cannot stand in for.
## Evidence
`src/shared/firebase-config.ts` ships a placeholder rather than a key:
```ts
export const FIREBASE_WEB_CONFIG: FirebaseWebConfig = {
apiKey: "REPLACE_WITH_FIREBASE_WEB_API_KEY",
authDomain: `${FIREBASE_PROJECT_ID}.firebaseapp.com`,
projectId: FIREBASE_PROJECT_ID,
};
```
`firebase apps:list --project bench-cockpit` returns "No apps found", and Google is not enabled as a sign-in provider. So `signInWithPopup` has no app to talk to and `securetoken.googleapis.com` has no key to accept.
## What the developer does
1. Firebase console → `bench-cockpit` → Project settings → Add app → **Web**.
2. Authentication → Sign-in method → enable **Google**.
3. Paste the resulting `apiKey` and `authDomain` into `src/shared/firebase-config.ts`.
4. `firebase deploy --only firestore:rules`.
No code changes beyond step 3. The whole path is already waiting on those values.
## Acceptance criteria
- [ ] `src/shared/firebase-config.ts` holds a real `apiKey`, committed.
- [ ] The rules are deployed to `bench-cockpit` — `firebase deploy --only firestore:rules` succeeds.
- [ ] "Turn on remote" in Settings completes a real Google sign-in and `GET /api/remote` reports the account.
- [ ] `/users/{uid}/machines/{machineId}` actually exists in the live Firestore console after connecting, with a `lastSeen` that advances.
- [ ] The daemon is left running past an hour and the ID token is still valid afterwards — the refresh loop has never run against the real endpoint for a full cycle.
- [ ] Restarting the daemon resumes without a second sign-in and without a second machine document.
- [ ] `DELETE /api/remote` removes the machine document from the live project.
- [ ] **Two machines.** A second laptop signed into the same account registers as a second machine document with a distinct id. This is the acceptance criterion from #45 that could not be checked with one machine, and it is the one that most needs a real second machine rather than a fake.
- [ ] A signed-in uid can read and write `/users/{ownUid}/x` and is denied on another uid's path — against the deployed rules, not the emulator.
## Why the rules check matters here
`tests/firestore-rules.test.ts` exists and is gated behind `BENCH_RULES_TEST=1`, but it has **never been executed**: current `firebase-tools` needs Java 21 and the machine it was written on has Java 11. Four lines of untested authorization is still untested authorization, and it is the only thing standing between one Google account and another's specialists.
Either install Java 21 and run `pnpm test:rules`, or check it by hand against the deployed rules. Do not skip it.
## Out of scope
- Anything from #46. Nothing is mirrored yet and nothing should be.
- Fixing #50's four pre-existing failures.
- #51.
## Verification
```
pnpm test:rules # needs Java 21 for the emulator
firebase deploy --only firestore:rules
```
Everything else on the list above is a manual check against the live project. Say which ones you actually did.
## Related
- #45 — the code, done and verified.
- Blocks #46, which cannot start until identity works for real.
- Design: `docs/superpowers/specs/2026-08-31-bench-over-firestore-design.md`
Contributor guide
Research direction
Start with src/shared/firebase-config.ts, tests/firestore-rules.test.ts, and the existing remote sign-in path from #45. Install Java 21 if needed, run pnpm test:rules, deploy with firebase deploy --only firestore:rules, then perform the listed live checks with one account on two machines. Done means real Google sign-in, correct rule enforcement, durable refresh and restart behavior, distinct machine documents, and successful deletion.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- firebase, java, typescript
- Domain
- authentication, cloud, databases, testing-qa
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 35/100