Protected Resident Council routes use an edge identity boundary and service-owned application checks. Voting uses scoped tokens for resident actions. Secrets remain deployment configuration and never belong in this public documentation.
House Desk and Pub have separate access applications and product-local authorization. Their trust boundary is documented in the IHNYC Service Docs.
Access boundaries by service
Resident Council website
- Public content is available without administrator credentials.
- Analytics and dataset tools require production edge protection where noted.
- Server functions treat edge policy and application validation as separate controls.
Sources: ihnyc-rc-landing/functions/api/stats.ts, ihnyc-rc-landing/functions/api/csv-upload.ts, ihnyc-rc-landing/README.md
RC Console
- RC Console verifies the Cloudflare Access JWT in application code.
- A static steward rule and the managed current-roster group control the front door.
- D1 people, assignments, and terms drive council membership and Console capabilities.
- Casework uses a separate, stricter Access application and a bounded role-owner feed.
- RC Console does not authorize House Desk or Pub operators.
Sources: ihnyc-rc-landing/rc-admin/src/middleware/auth.ts, ihnyc-rc-landing/rc-admin/src/roster.ts, ihnyc-rc-landing/rc-admin/src/authz.ts
Resident voting
- Admin routes require Cloudflare Access identity or the narrow
ADMIN_API_KEYrecovery path. - Vote submissions validate invitation tokens through the TokenManager Durable Object before storing a ballot.
- IP-based rate limits constrain submission abuse.
Sources: ihnyc-rc-vote/src/middleware/auth.ts, ihnyc-rc-vote/src/routes/vote.ts, ihnyc-rc-vote/src/middleware/rate-limit.ts
IHNYC Games
- Public events, standings, and roster summaries are readable without administrator credentials.
- Mutation, import, and submission-review routes require the Games administrator boundary.
Sources: ihnyc-games/services/api/src/index.ts
Gallery (decommissioned)
The retired implementation protected /admin and /api/admin at the edge with Cloudflare Access. Its documentation remains a historical record, not an operational runbook.
Sources: ihnyc-rc-gallery/src/index.ts, ihnyc-rc-gallery/README.md
Identity and authorization
flowchart LR ACCESS["Cloudflare Access<br/>Who is this?"] --> APP["Service middleware<br/>Verify identity"] APP --> POLICY["Service-owned policy<br/>May this identity act?"] POLICY -- "allowed" --> HANDLER["Run handler"] POLICY -- "denied or unknown" --> STOP["Deny"]
Cloudflare Access admission alone is not a product permission. Each active service must still validate the request and enforce its own authorization rule. Machine-to-machine integrations use dedicated, audience-bounded credentials rather than a browser identity.
Secret handling
| Service | Storage method | Boundary |
|---|---|---|
| Resident Council website | Pages environment variables and secrets | GitHub and analytics integrations |
| RC Console | Wrangler secrets | Access management, health, alerts, and bounded service feeds |
| Voting | .dev.vars locally; Wrangler secrets in production | Administration, email, and token services |
| Games | Deployment secrets and bindings | Administrator and storage integrations |
Never publish secret values, tokens, cookies, recovery codes, private infrastructure addresses, resident records, or unsanitized logs.
Verification questions
- Does the production edge policy cover every route marked protected?
- Does application code deny a missing, malformed, or unauthorized identity?
- Is a recovery credential narrower than ordinary full administration?
- Can a new route fail closed until its authorization mapping is reviewed?
- Do logs and health endpoints omit resident data and credential material?