import { Hono } from 'hono'
import { useWorkersLogger } from 'workers-tagged-logger'

import { getAccount, updateAccount } from '@repo/domain/src/accounts-db'
import { PlatformType } from '@repo/domain/src/enums'
import { countOnlinePlayers } from '@repo/domain/src/presence-db'
import { getStatSeries } from '@repo/domain/src/stats-db'
import { logger, withDefaultCors, withOnError } from '@repo/hono-helpers'
import { validateAndGetAccountId } from '@repo/jwt'

// The `platform_account` link table, owned (and migrated) by the `auth` worker. A claimed
// Discord identity is stored there as a PlatformType.Discord link — it is an account ↔
// external identity exactly like the Steam and Meta ones, and unlike a field on the
// account blob it can answer "is this Discord user already on another account" from an
// index. Nobody logs in with it: `auth` refuses a cached_login for any platform it can't
// verify, and its picker lists only the platforms that can be (CACHED_LOGIN_PLATFORMS).
import {
	countAccountsForPlatformIdentity,
	getLinksForAccount,
	isPlatformIdentityLinked,
	linkPlatformIdentity,
} from '../../auth/src/platform-db'
import { authUnreachable } from './auth-messages'
import {
	AUTHORIZE_URL,
	discordConfig,
	exchangeCode,
	fetchGuildMembership,
	qualifies,
	redirectUri,
	revokeToken,
	SCOPES,
} from './discord'
import { docsPage, fetchSpec } from './docs'
import { privacyPage } from './privacy'
import {
	banReportHandler,
	bansInForceHandler,
	createReportHandler,
	getReportHandler,
	linkedAccountsHandler,
	playerHistoryHandler,
	requireStaff,
	searchReportsHandler,
	topReportedHandler,
} from './staff'
import { turnstileKeys, verifyTurnstile } from './turnstile'
import {
	accountsBase,
	apiBase,
	authBase,
	cdnBase,
	imgBase,
	notifyBase,
	postAuthForm,
	readAuthError,
	roomsBase,
	storageBase,
} from './upstream'

import type { Context } from 'hono'
import type { App } from './context'

/**
 * www — the website worker. It serves the React SPA (create account, sign in, change
 * username/email/password) and almost nothing else: the SPA calls the SAME endpoints
 * the game does, on `auth`/`accounts`/`api`/`notify` directly, exactly as rec.net's own
 * site did. Those workers answer CORS for it, and the browser holds the access token.
 *
 * Two things stay server-side here, both because they can't work any other way:
 *
 *  - `/api/signup`, because it's gated by Turnstile and the secret key that turns a
 *    widget token into a verdict cannot ship to a browser. It's also the one account
 *    endpoint with no game equivalent — the game never creates password accounts — so
 *    there's no client contract being duplicated.
 *  - `/api/config`, which tells the SPA the Turnstile site key and where the other
 *    workers live, so one client build works for any operator's domain.
 *  - `/api/benefits/*`, the Discord-verified benefits claim, for the same reason as
 *    signup: the OAuth2 client secret that turns Discord's authorization code into an
 *    access token can't ship to a browser. It is also the only route here that writes to
 *    the database, and so the only one that verifies a token itself (see the section).
 */

/**
 * The account behind a request's bearer token, or null.
 *
 * www verifies a token itself for exactly one feature. Everywhere else the browser
 * carries its token to the worker that owns the data (`accounts`, `rooms`, …) and that
 * worker does the checking; but the benefits claim WRITES `hasPlus` onto an account row,
 * and "which account" is the whole question — asking the SPA would let anyone grant Plus
 * to any id. Same key, same `@repo/jwt` validation (signature, exp) every other worker
 * runs.
 */
const claimant = async (c: Context<App>): Promise<number | null> =>
	validateAndGetAccountId(c.req.raw, await c.env.JWT_SECRET.get())

/**
 * The Discord consent URL the SPA sends the player to, fully assembled here rather than
 * in the browser — everything in it (the scopes the claim needs, and the redirect URI,
 * which must match the token exchange byte for byte) is this worker's business, and a
 * page that built its own could drift from what `/api/benefits/claim` will accept.
 *
 * It carries no `state`. That is the SPA's to add and to check on the way back: it's a
 * per-attempt CSRF nonce, so it has to be minted by the thing that will later verify it
 * (see App.tsx). Everything else about the request is fixed by the server.
 */
function authorizeUrl(request: Request, clientId: string): string {
	const url = new URL(AUTHORIZE_URL)
	url.search = new URLSearchParams({
		client_id: clientId,
		response_type: 'code',
		scope: SCOPES,
		redirect_uri: redirectUri(request),
		// Skip Discord's "you've already authorized this app, continue?" interstitial on a
		// repeat claim; the player has already pressed a button that says what this does.
		prompt: 'none',
	}).toString()
	return url.toString()
}

/**
 * The windows `/api/stats/online` serves, each with the bucket its samples are folded
 * into. The `match` cron samples every five minutes, so `24h` is the raw series and the
 * rest are sized to land between ~90 and ~290 points — what a chart the width of the page
 * can actually draw. A closed list rather than a free `since`: every request scans the
 * window it names, and this is a public route.
 */
const STAT_RANGES: Record<string, { seconds: number; bucketSeconds: number }> = {
	'24h': { seconds: 86_400, bucketSeconds: 300 },
	'7d': { seconds: 7 * 86_400, bucketSeconds: 3_600 },
	'30d': { seconds: 30 * 86_400, bucketSeconds: 4 * 3_600 },
	'90d': { seconds: 90 * 86_400, bucketSeconds: 86_400 },
}

const app = new Hono<App>()
	.use(
		'*',
		// middleware
		(c, next) =>
			useWorkersLogger(c.env.NAME, {
				environment: c.env.ENVIRONMENT,
				release: c.env.SENTRY_RELEASE,
			})(c, next)
	)

	.onError(withOnError())

	// ---- Site config --------------------------------------------------------

	// What the SPA has to know before it can do anything: whether web signup is open,
	// the Turnstile site key to mount its widget with, and the hostnames of the workers
	// it calls directly. All three are served rather than baked into the client build so
	// one build works for any operator. The site key is public (it ships in the widget
	// markup either way); the secret never leaves the worker.
	.get('/api/config', async (c) => {
		const [keys, discord] = await Promise.all([turnstileKeys(c.env), discordConfig(c.env)])
		return c.json({
			signupEnabled: keys !== null,
			turnstileSiteKey: keys?.siteKey ?? null,
			// The benefits claim, on the same terms: open only when it's fully configured, and
			// the SPA is handed a ready-made consent URL rather than the parts to build one.
			// Nothing secret is served — the client id inside it is public — and the guild/role
			// ids never leave the worker, since it's the worker that asks Discord the question.
			benefitsEnabled: discord !== null,
			discordAuthorizeUrl: discord ? authorizeUrl(c.req.raw, discord.clientId) : null,
			hosts: {
				auth: authBase(c.env),
				accounts: accountsBase(c.env),
				api: apiBase(c.env),
				img: imgBase(c.env),
				notify: notifyBase(c.env),
				rooms: roomsBase(c.env),
				cdn: cdnBase(c.env),
				storage: storageBase(c.env),
			},
		})
	})

	// ---- Server status ------------------------------------------------------

	// A public, unauthenticated snapshot of the server — what a status page, a Discord
	// bot or the homepage can poll without a token. CORS is open on this one route (the
	// rest of www is same-origin) so a page hosted anywhere can read it.
	//
	// `status` is a stub: this handler only runs when the worker is up, so there is no
	// state in which it answers anything but "online". It's here so callers can key off
	// a field rather than off HTTP 200, and so a real health signal can replace the
	// constant without changing the payload's shape.
	.get('/server-status', withDefaultCors(), async (c) => {
		return c.json({
			status: 'online',
			// One presence row per account, expired rows excluded — see countOnlinePlayers.
			// Players sitting in the lobby count as online, same as anywhere else we read
			// presence.
			players: await countOnlinePlayers(c.env.DB),
		})
	})

	// The history behind that head-count: the `online` series the `match` presence cron
	// samples into `stat`, for the chart at `/stats`. Public and CORS-open on the same
	// terms as `/server-status`.
	//
	// Each point is the PEAK of its bucket, not the mean — "how many were on" is a question
	// about the busiest moment, and a mean over a four-hour bucket flattens an evening's
	// spike into nothing. `average` is over the raw samples, not over the buckets, so a
	// short bucket at the window's edge doesn't weigh the same as a full one. `online` is
	// the live count rather than the last sample, which can be five minutes old.
	.get('/api/stats/online', withDefaultCors(), async (c) => {
		const range = c.req.query('range') ?? '24h'
		const window = STAT_RANGES[range]
		if (!window) return c.json({ error: 'Unknown range.' }, 400)

		const now = Date.now()
		const since = new Date(now - window.seconds * 1000)
		const [online, buckets] = await Promise.all([
			countOnlinePlayers(c.env.DB),
			getStatSeries(c.env.DB, 'online', since, window.bucketSeconds),
		])
		const samples = buckets.reduce((n, b) => n + b.samples, 0)
		// A new sample lands every five minutes, so a minute of browser cache costs nothing
		// anyone can see and spares the scan when someone flips between ranges.
		c.header('cache-control', 'public, max-age=60')
		return c.json({
			range,
			bucketSeconds: window.bucketSeconds,
			// The window itself, so the chart's x-axis spans what was ASKED for rather than
			// what came back — a server with three days of history shows three days of line.
			from: Math.floor(since.getTime() / 1000),
			to: Math.floor(now / 1000),
			online,
			peak: buckets.reduce((max, b) => Math.max(max, b.peak), 0),
			average: samples === 0 ? 0 : buckets.reduce((sum, b) => sum + b.sum, 0) / samples,
			points: buckets.map((b) => ({ t: b.t, players: b.peak })),
		})
	})

	// ---- Signup -------------------------------------------------------------

	// Create an account from the website, behind a Turnstile bot check. The check is what
	// makes this safe to leave open: `auth` binds no platform identity to a web account, so
	// its per-IP cap (3, never decaying) is the only other thing in front of this path —
	// and `auth` has no bot check of its own, which is why this one endpoint can't simply
	// be called from the browser like the rest.
	//
	// Deliberately passes NO `platform`: create_account treats an asserted platform as one
	// to verify against Steam and would reject RecNet, so this is the platform-less
	// password-account path. The username is auto-assigned by auth — players don't pick one.
	//
	// On success auth's token response is returned VERBATIM, so the SPA stores it the same
	// way it stores the one it gets from calling `/connect/token` itself to sign in. The
	// account's email, when the player gave one, is saved by the client afterwards with
	// that token — `create_account` takes no email, and `accounts` owns the field.
	.post('/api/signup', async (c) => {
		// No usable keypair means signup is closed rather than unprotected (see turnstile.ts).
		const keys = await turnstileKeys(c.env)
		if (!keys) return c.json({ error: 'Account creation is currently disabled.' }, 403)

		type SignupBody = { password?: string; turnstileToken?: string }
		const { password, turnstileToken } = await c.req
			.json<SignupBody>()
			.catch(() => ({}) as SignupBody)
		if (!password) return c.json({ error: 'A password is required.' }, 400)
		if (!turnstileToken) return c.json({ error: 'Please complete the bot check.' }, 400)

		// The IP Turnstile cross-checks the token against — set by the edge, so the client
		// can't spoof it (unlike X-Forwarded-For). `auth` records the same header as the
		// account's signup IP, which is why it's forwarded to the grant below rather than
		// left to the edge: see `postAuthForm`.
		const clientIp = c.req.header('cf-connecting-ip')
		const verified = await verifyTurnstile(keys.secretKey, turnstileToken, clientIp)
		// A token is single-use, so the client resets its widget before letting them retry.
		if (!verified) return c.json({ error: 'Bot check failed. Please try again.' }, 403)

		// A throw here is auth being unreachable, not a rejected signup — answered as such
		// rather than falling through to the generic 500 handler, whose "internal server
		// error" tells the player nothing about whether they now have an account (they don't:
		// nothing was created).
		const res = await postAuthForm(
			c.env,
			'/connect/token',
			{ grant_type: 'create_account', password },
			{ clientIp }
		).catch(() => null)
		if (res === null) {
			logger.error('could not reach auth to create an account')
			return c.json({ error: authUnreachable('signup') }, 502)
		}

		// A refused grant is translated (see `readAuthError`) rather than relayed: auth
		// answers the OAuth shape, whose `error` is always a code like `invalid_grant`, and
		// that code is what the form used to show for every failure — including the
		// per-network cap, which the player could otherwise understand. Sign-in doesn't need
		// this (the browser calls `/connect/token` itself and reads `error_description`), but
		// the cap is reachable only from signup, so the sentences live on this path.
		if (!res.ok) {
			const failure = await readAuthError(res, 'signup')
			logger.info('auth refused a signup', { status: res.status, upstream: failure.upstream })
			return c.json({ error: failure.message }, failure.status)
		}

		const token = (await res.json().catch(() => null)) as { access_token?: string } | null
		if (!token?.access_token) {
			logger.error('auth answered a signup with no access_token')
			return c.json({ error: authUnreachable('signup') }, 502)
		}
		return c.json(token)
	})

	// ---- Discord benefits claim ---------------------------------------------

	/**
	 * Where the player's Discord already stands with this account — what the claim page
	 * renders before anyone presses anything, so a player who has already claimed sees
	 * that rather than being walked through the flow again to find out.
	 *
	 * `hasPlus` is read from the account row rather than from a token claim: it is set
	 * here, after the token in the browser was issued, so a freshly-claimed player's token
	 * says nothing about it until they sign in again.
	 */
	.get('/api/benefits/status', async (c) => {
		const accountId = await claimant(c)
		if (accountId === null) return c.body(null, 401)
		const [account, links] = await Promise.all([
			getAccount(c.env.DB, accountId),
			getLinksForAccount(c.env.DB, accountId),
		])
		return c.json({
			hasPlus: account?.hasPlus ?? false,
			// Whether this account is already tied to a Discord identity — not WHICH one. The
			// player knows their own Discord; the id is of no use to the page and every reason
			// to keep an account's linked identities off the wire.
			linked: links.some((link) => link.platform === PlatformType.Discord),
		})
	})

	/**
	 * Redeem a Discord authorization code and, if the player holds the configured role in
	 * the configured guild, give the account Rec Room Plus.
	 *
	 * The browser sends ONLY the code. It never sees an access token: the exchange happens
	 * here with the client secret, the roles are read with the resulting token, and the
	 * token is handed straight back to Discord (see discord.ts). The redirect URI is
	 * derived from this request's own origin rather than accepted from the body, so the
	 * secret can't be used to redeem codes issued for somebody else's page.
	 *
	 * The claim is once-only PER DISCORD USER, not per account: the Discord id is stored
	 * beside the flag, and a code from a Discord member who has already claimed elsewhere
	 * is refused. Otherwise one person with the role could walk it around every account
	 * they own. Re-claiming on the same account is allowed and simply re-affirms the flag,
	 * which is what makes the page safe to reload and a lapsed-then-restored role
	 * re-claimable.
	 *
	 * Nothing here ever REVOKES Plus: losing the Discord role later leaves the flag set.
	 * That's deliberate for now — a sweep would need a bot token to enumerate the guild,
	 * which this design specifically avoids — but it does mean the flag records "held the
	 * role once", not "holds it today".
	 */
	.post('/api/benefits/claim', async (c) => {
		const config = await discordConfig(c.env)
		if (!config) return c.json({ error: 'Benefit claims are currently disabled.' }, 403)

		const accountId = await claimant(c)
		if (accountId === null) {
			return c.json({ error: 'Please sign in before claiming your benefits.' }, 401)
		}

		type ClaimBody = { code?: string }
		const { code } = await c.req.json<ClaimBody>().catch(() => ({}) as ClaimBody)
		if (!code) return c.json({ error: 'No Discord authorization code was provided.' }, 400)

		const accessToken = await exchangeCode(config, code, redirectUri(c.req.raw))
		// A code lives about a minute and is single-use, so this is far and away the most
		// likely failure a real player hits — hence a sentence about starting over rather
		// than a relayed OAuth code, which would tell them nothing.
		if (accessToken === null) {
			return c.json(
				{ error: 'That Discord sign-in could not be completed. Please try again.' },
				400
			)
		}

		const membership = await fetchGuildMembership(accessToken, config.guildId)
		// The token has told us everything it can; hand it back before answering, whatever
		// the answer turns out to be. Awaited rather than fired into the void so a Worker
		// that finishes the response can't cancel it.
		await revokeToken(config, accessToken)

		if (membership === null) {
			return c.json({ error: 'You are not a member of our Discord server.' }, 403)
		}
		// Any ONE of the configured roles qualifies — see `qualifies`. The message stays
		// singular-ish and names no role: which roles qualify is the operator's business to
		// advertise in their own server, and listing them here would leak the guild's role
		// layout to anyone who pressed the button.
		if (!qualifies(membership.roles, config.roleIds)) {
			return c.json({ error: 'Your Discord account does not have a qualifying role.' }, 403)
		}

		// The once-only guard, asked of the link table: is this Discord identity already on an
		// account, and is that account someone else's? Re-claiming on the caller's OWN account
		// is the idempotent case and must fall through — it's how a player whose role lapsed
		// and came back re-affirms Plus, and it's what makes the page safe to reload.
		//
		// `countAccountsForPlatformIdentity` counts EVERY link for the identity, unfiltered by
		// platform, which is why the claim can use the same helper `auth`'s per-identity
		// signup cap does.
		const alreadyMine = await isPlatformIdentityLinked(
			c.env.DB,
			accountId,
			PlatformType.Discord,
			membership.userId
		)
		if (!alreadyMine) {
			const claimedElsewhere = await countAccountsForPlatformIdentity(
				c.env.DB,
				PlatformType.Discord,
				membership.userId
			)
			if (claimedElsewhere > 0) {
				logger.info('a discord account tried to claim benefits on a second account', {
					accountId,
				})
				return c.json(
					{ error: 'That Discord account has already claimed benefits on another account.' },
					409
				)
			}
		}

		// Both writes are idempotent: the link is INSERT OR IGNORE (so `linkedAt` keeps the
		// FIRST claim's time), and the flag is already true on a re-claim.
		await linkPlatformIdentity(c.env.DB, accountId, PlatformType.Discord, membership.userId)
		await updateAccount(c.env.DB, accountId, { hasPlus: true })
		logger.info('granted plus from a discord benefits claim', { accountId })

		// The username is echoed for the confirmation line only — it is never stored, and a
		// Discord member who has since renamed themselves is not a problem to solve here.
		return c.json({ hasPlus: true, discordUsername: membership.username })
	})

	// ---- Staff moderation panel ---------------------------------------------
	// The endpoints behind `/moderation` in the SPA. They live here rather than on `api`
	// (which owns the `report` table) because they are a recflare addition with no
	// counterpart in the real service, and the game-facing workers only reimplement what
	// the client actually calls — see src/staff.ts. The SQL stays with the table.
	//
	// Ordered before the ASSETS catch-all like everything else, and covered by the
	// existing `/api/*` entry in wrangler.jsonc's `run_worker_first`, so no routing change
	// was needed. `/moderation` itself is deliberately NOT in that allowlist: it is a
	// client-side route, so it must fall through to the SPA shell.
	.use('/api/staff/*', requireStaff)

	// Registered before `/api/staff/reports/:id` so the literal path isn't captured as an
	// id — `top-reported` is not a number, but the param route would still match it and
	// answer a 400 instead of the list.
	.get('/api/staff/reports/top-reported', topReportedHandler)
	.get('/api/staff/reports', searchReportsHandler)
	.post('/api/staff/reports', createReportHandler)
	.get('/api/staff/reports/:id', getReportHandler)
	.post('/api/staff/reports/:id/ban', banReportHandler)
	.get('/api/staff/bans', bansInForceHandler)
	.get('/api/staff/players/:id', playerHistoryHandler)
	.get('/api/staff/players/:id/linked', linkedAccountsHandler)

	// ---- Privacy policy -----------------------------------------------------
	// Server-rendered rather than a SPA route so the page has real text without
	// JavaScript: the Meta Horizon Store re-fetches this URL to check the policy is
	// still live, and an empty SPA shell can read as a broken link (see privacy.ts).
	.get('/privacy', (c) => c.html(privacyPage()))

	// ---- Aggregated API docs ------------------------------------------------
	// `/docs` serves the self-hosted Scalar UI; `/docs/openapi/:service.json` proxies
	// each worker's spec same-origin (see docs.ts). The Scalar bundle itself
	// (`/docs/scalar.standalone.js`) is a static asset emitted by the vite build, so it
	// falls through to the ASSETS catch-all below.
	.get('/docs', (c) => c.html(docsPage()))
	.get('/docs/openapi/:service', async (c) => {
		// Scalar requests `auth.json`; strip the suffix to get the service slug. The
		// param is a single path segment, and fetchSpec allowlists it (so this can't be
		// coerced into an open proxy).
		const slug = c.req.param('service').replace(/\.json$/, '')
		const spec = await fetchSpec(c.env, slug)
		if (spec === null) return c.notFound()
		return spec
	})

	// ---- Static SPA ---------------------------------------------------------
	// Everything else is served from the built client assets. With
	// `not_found_handling: single-page-application`, unknown routes return
	// index.html so the React app can handle client-side routing.
	.all('*', (c) => {
		if (!c.env.ASSETS) return c.notFound()
		return c.env.ASSETS.fetch(c.req.raw)
	})

export default app