AUTH · WHO POINTCAST KNOWS YOU AS

Your state, right now.

PointCast supports three kinds of identity: an anonymous session (auto-generated, every visitor gets one in localStorage['pc:session-id']), a Google-OAuth session (cookie pc_session, 30-day, 30-day, issued by /api/auth/google/callback), and one or more connected Tezos wallets (via Beacon, stored in pc:wallets). This page shows what you are right now + the setup steps needed for the server-side flows to actually resolve.

YOUR STATE

  • SESSION (ANONYMOUS)

    —

    Every visitor gets one. Anchors your noun and your local game state.

  • GOOGLE (OPTIONAL)

    —

    Set once, lasts 30 days. Needed for cross-device identity. Route returns 404 until env vars set.

  • TEZOS WALLET (OPTIONAL)

    —

    Beacon wallet pairing for collecting, tipping, and federation-identity.

SIGN IN

SETUP NOTES · FOR MIKE

1. Google OAuth env vars

The /api/auth/google/start + /callback endpoints are written (see functions/api/auth/google/start.ts + callback.ts) but return a 503 config-error until the Cloudflare Pages dashboard has three env vars set for the Production environment:

  • GOOGLE_CLIENT_ID — from Google Cloud Console, OAuth 2.0 Client IDs
  • GOOGLE_CLIENT_SECRET — the matching secret
  • GOOGLE_REDIRECT_URI — must exactly match an authorized redirect URI registered in Google Cloud Console. Recommended: https://pointcast.xyz/api/auth/google/callback

Dashboard path: Cloudflare Pages → pointcast project → Settings → Environment variables → Production → Add variable. Add all three, save, trigger a re-deploy (pushing any commit works, or run npx wrangler pages deploy dist --branch main again). After that, /api/auth/google/start returns a 302 to Google's OAuth dialog.

Google Cloud Console steps (in case you need a refresher): APIs & Services → Credentials → + Create credentials → OAuth 2.0 Client ID → Application type: Web application → Authorized redirect URIs: the one above. Copy client ID + client secret into Cloudflare.

2. Tezos Beacon wallet

The /profile page has the Beacon wallet pairing flow already wired via the WalletChip component. Visitors click, Beacon opens, they approve, the address lands in pc:wallets. Cross-session identity confirmation runs via /api/wallet/me which returns { recognized: true, identity: "mike" } when the connected address matches Mike's tz2 seller address. No additional setup needed; this works today.

3. Session cookie caveat (v0)

The pc_session cookie issued by the callback is a base64-encoded JSON blob, NOT a JWT. It's unsigned — anyone with browser access could mint one. Treat as an identity hint, never as an auth credential gating anything valuable. v1 ships JWT signing once a GOOGLE_SESSION_SECRET env var is wired + a small signing helper in functions/api/auth/session.ts.

4. Where auth state is visible in the UI

  • The HUD bar (bottom of every page): YOU panel shows noun + mood + stats; sign-in chip reveals only when pc_session cookie is absent.
  • The /cos page: composer foot has a "sign in with Google" chip when logged out.
  • /noundrum header: tiny ↪ G chip in upper right when logged out.
  • This page (/auth): the definitive status + setup reference.