MotorSignal-App/docs/website-firebase-admin-blocker-2026-10-04.md

Website Firebase Admin runtime configuration investigation

Date: 2026-10-04. Latest result: USER-CONFIRMED production authenticated community empty state after administrator configuration. Populated production discovery remains untested. This documentation update did not rebuild, redeploy, restart, rerun configuration, or independently recheck production.

User-confirmed production follow-up

Evidence source: the administrator's direct report in this conversation on 2026-10-04, not a new agent browser/SSH verification. The administrator reports applying the configuration from docs/website-firebase-admin-administrator-commands-2026-10-04.md.

Check	Latest result and provenance
Credential probes	PASS — user-confirmed
Administrator configuration and website restart	Completed — user-confirmed; no agent configuration rerun
Deployed revision	Unchanged at 8b3a7aa — user-confirmed; existing full revision is 8b3a7aa29290b58a9456a564785e9c73cd8e3093
Guest discovery	401 — user-confirmed
Post-restart credential/discovery failures	Zero — user-confirmed
Signed-in Group Ride Hub community empty state	PASS — user-confirmed: No Community Rides Scheduled appears
Populated production discovery	UNTESTED
Raw authenticated HTTP status/JSON	Not supplied or independently captured in this follow-up; no claim of inspected HTTP 200 or response payload

This user-confirmed result supersedes the historical missing-credential blocker for the production empty-state workflow. It does not establish populated discovery, ordering, pagination, blocking/exclusions, or other production behaviors. Exact live identity, IAM grants, file contents, and rollback-backup presence were not independently inspected after application. The administrator runbook retains the configuration rollback procedure; it was not exercised here. Existing isolated/regression evidence remains separate from this production confirmation.

Historical investigation scope

Initial result before administrator application: BLOCKED on privileged execution and identity approval/permission verification. During that agent investigation, no production configuration was changed and no rebuild, restart, key generation, credential copy/export, commit, push, fixture, IAM change, or rules change occurred. The sections below preserve the original pre-configuration observations and plan; they are not current post-configuration assertions.

Initial confirmed cause and provisioning

• Deployed revision remains 8b3a7aa29290b58a9456a564785e9c73cd8e3093 (GET /api/version: 200).
• The deployed server loader supports explicit FIREBASE_SERVICE_ACCOUNT or Application Default Credentials, including GOOGLE_APPLICATION_CREDENTIALS. Its production project fallback is motoapp-d22e0.
• motorsignal-website.service runs as motorsignal. It has no EnvironmentFile, no drop-in, no credential environment variable, and no website .env* file. Its existing environment preserves port 3001 and production settings.
• /etc/motorsignal/firebase-admin.json exists, mode 0600, owner/group motorsignal. The service user can read it by ownership; the SSH inspector cannot.
• /etc/motorsignal/routing.env, root-owned 0640, references that credential and project motoapp-d22e0. Active motorsignal-routing.service loads this file. This establishes routing provisioning, not website reuse approval or adequate Firestore permissions.
• Backend production.env specifies the same Firebase project but no Admin credential reference. It contains unrelated database/mail/session secrets and was not copied.
• The existing SSH key cannot authenticate as root. sudo -n true and a read-only check as motorsignal both return sudo: a password is required. Passwordless commands include website restart/status, but not credential inspection, systemd configuration edits, or daemon-reload. An opaque legacy staging helper was not invoked.

The security review therefore kept the routing identity untouched. The exact service-account email, credential validity, approved website purpose, IAM grants, and Firestore effective read permissions remain unknown. A filename and matching project variable do not prove them.

Initial production checks (before administrator application)

Check	Result
Existing authorized authenticated session	Restored; no sign-in or token extraction
Community discovery	Reproduced error UI and server_error browser warning; website status logs at 06:59:45 UTC show ADC loading failure
Successful structured authenticated response	BLOCKED; no successful response observed
Legitimate empty result display	NOT VERIFIED; failed request is not an empty result
Unauthenticated GET /api/group-rides	PASS: 401, {"error":"unauthorized"}
Credential-loading failures cleared	FAIL: still present; no fix applied
Revision and website availability	PASS: version 200, exact deployed revision; website service active

Commands: read-only SSH systemctl show, metadata listings, sanitized inspect-runtime.py, allowed sudo -n /usr/bin/systemctl status motorsignal-website; browser navigation and community tab; local node output/deployment/20261004-firebase-admin/smoke.mjs. No broad suites were rerun.

Original privileged provisioning plan (administrator now reports applied)

An administrator must first inspect only credential type, project_id, and client_email under the service user, without outputting the remaining JSON. For example, this read-only command does not print keys or tokens:

sudo -u motorsignal /usr/bin/python3 -c 'import json; d=json.load(open("/etc/motorsignal/firebase-admin.json")); print(json.dumps({k:d.get(k) for k in ("type","project_id","client_email")}))'

The identity owner/project administrator must confirm its intended website use and effective Firestore read permissions for the production database: community group_rides, participant documents, and users/*/blocks reads. The current website Admin routes are read-only; no Firebase Auth administration grant is requested. The necessary document get/list permissions are datastore.entities.get and datastore.entities.list; the predefined roles/datastore.viewer includes these, but grants access to all Firestore resources and is not an instruction to broaden an existing identity. Verify current grants/conditions and least privilege with the project owner. Google Firestore IAM documentation

If this routing identity is approved and adequate, reference the existing file in place, without copying or changing its permissions. Otherwise provision an already-approved website identity through the same secure /etc/motorsignal runtime mechanism, using an existing credential or approved keyless ADC configuration. Do not generate a new service-account key as a workaround. The exact account email cannot be specified until privileged metadata inspection succeeds.

After that validation, use a website-specific runtime environment file (proposed /etc/motorsignal/website.env, root-owned 0640, group motorsignal), containing only non-secret settings:

FIREBASE_PROJECT_ID=motoapp-d22e0
GOOGLE_APPLICATION_CREDENTIALS=/etc/motorsignal/firebase-admin.json

The credential path above is conditional on approval; use the approved identity's path otherwise. Load it from proposed /etc/systemd/system/motorsignal-website.service.d/10-firebase-admin.conf:

[Service]
EnvironmentFile=/etc/motorsignal/website.env

Do not point the website at routing.env or production.env: they include unrelated settings/secrets and routing's port. Do not add credential JSON to Next.js configuration, .next, public assets, or any NEXT_PUBLIC_* variable. Preserve existing website port/backend settings; no emulator variables are permitted.

Back up the prior website unit, drop-ins, and any existing website-specific environment file into a root-only backup directory before edits. Record which files did not exist. Then privileged systemctl daemon-reload, followed by restarting only motorsignal-website, is required. No code rebuild is necessary. These steps were documented, not executed.

Verify after restart with the existing authorized session: actual authenticated response status/JSON, eligible rides or genuine empty UI, unauthenticated 401, post-restart logs free of credential failures, unchanged revision. Any index or IAM failure is a separate reported blocker, not grounds for rules changes or fixtures.

Historical rollback and preservation notes

No rollback is currently necessary because configuration is unchanged. No new production configuration backup was created.

For a future application of the proposed change, restore the prior website unit/drop-ins/environment files from the protected backup, or move newly added website-only files back into that backup when their previous state was absent. Run privileged daemon-reload and restart only the website. Do not remove or alter the shared routing credential. Keep deployed code revision unchanged. The earlier code rollback archive is unrelated to this configuration rollback.

Only new local evidence files and this report were added. Hash verification confirms all 117 files from the existing pre-deployment dirty-file baseline remain unchanged. Existing main-workspace changes remain unstaged; deployment worktree remains clean. The temporary authenticated verification tab was closed without signing out. A non-secret read-only inspector was uploaded to /home/motorsignal-admin/inspect-website-credentials-20261004.py and retained for the administrator; it does not contain credentials.

Evidence: output/deployment/20261004-firebase-admin/runtime-inventory.json, authenticated-check.json, http-smoke.json, git-final.json, and the corresponding non-secret inspection/smoke/preservation scripts.