Shrinko

The service needs two auth paths - platform-created username/password accounts and Supabase Google OAuth - but they must produce one session carrier so that every protected route, dashboard query, and ownership check treats requests identically regardless of which provider authenticated them. Duplicating authentication per route would fork the codebase: one branch per provider, two places to forget a check, two response shapes. Worse, the raw password must never cross from the credential-verification routes into downstream business logic, and the client-side PKCE flow adds its own failure mode - Supabase JWT validation fails silently when the device clock is wrong.

Built a single resolver, resolveUserId(), that reads the Authorization header first; if it carries a Bearer token it is validated with supabase.auth.getUser() and the Supabase user id is returned, otherwise the sid cookie is hashed with SHA-256 and matched against the users.sid column. Route handlers never see which provider authenticated the request - they receive only an id or null. Registration validates every field with shared regexes (username 5-15 lowercase alphanumeric, password 8-20 with four character classes, names letters-only), checks username uniqueness before insert, and derives the credential digest from a salted composition of username and password so identical passwords never produce identical digests. The login endpoint additionally answers malformed or missing credentials only after a randomized 300-400 ms pause, so request timing cannot be used to probe the validation path. Login rotates the session token on every success and both flows set one cookie format: maxAge 3600, SameSite Lax, Secure, intentionally not HttpOnly because the client-side session-aware UI must be able to see it. The landing page also probes its own Date header with a HEAD request and warns when the device clock is off by more than 60 seconds, catching the PKCE failure mode before the user attempts sign-in.

Centralizing identity behind one function means adding a third provider means extending the resolver, not rewriting middleware or re-registering protected routes. The 128-character token is generated server-side, stored only as a hash, and rotated on every login, so a stolen cookie is automatically dead as soon as the owner signs in again and at most one hour old by client expiry. Keeping the cookie JS-readable is a deliberate trade: the dashboard needs to detect auth state on page load, so HttpOnly was rejected in favor of making the token itself short-lived and revocable by rotation. The clock-skew probe exists because PKCE exchange results in a JWT whose validation is unforgiving - a wrong device clock produces a generic offline failure with no actionable error, so the client warns proactively.

Sessions, link-monitor keys, and passwords are all capability-bearing secrets. If they are stored in plaintext, a database read becomes instantaneous account takeover, anonymous-link hijacking, and credential recovery - and here the database client is a service-role Supabase key that bypasses Row-Level Security, so the edge runtime itself holds a path to every row. The additional requirement is that link owners need a secret to view analytics and delete their link without an account, so the capability key must be issued once and be usable forever after - plaintext storage would be the obvious but fatal way to satisfy that.

Every secret in the system follows the same pattern: generate high-entropy randomness with crypto.randomInt, hand the plaintext to the client exactly once, and persist only a digest. Session ids are 128 characters, stored as SHA-256(sid) in users.sid and rotated on each login. Monitor keys are 64 characters; createShortLink() hashes them with hashMonitorKey() before insert and returns the plaintext key in the response payload, after which only the hash exists on disk. Passwords are hashed with SHA-256 over a SALT-wrapped input via a shared formatWithSalt() primitive, and because the username is bound into the digest, two users with identical passwords still produce different stored values. The SALT comes from the environment and the application refuses to boot without it, so misconfiguration fails loudly instead of producing a working-but-unseeded hasher.

Storing digests means the database is no longer a credential store - a leak yields nothing that can authenticate. The deterministic salted digest also allows credentials to be re-derived at will: login re-computes the hash, a password change is a single UPDATE of the auth column, and the monitor-key lookup is an equality query against the stored digest. The one-time plaintext issuance keeps the capability secret on the wire for a single response, after which possession of the database is insufficient to manage the link.

The application talks to Supabase with the service-role key, which deliberately bypasses Row-Level Security: Postgres will return or mutate whatever the app asks for. That moves the entire authorization boundary into the application layer, where a single forgotten filter - a details query keyed only by short_url, a delete keyed only by the alias - becomes a broken-object-level access hole exposing every user's links and click data. On top of that, links created without an account have no user id, so anonymous ownership has to be expressed as a separate capability that must not be guessable or blindable.

Every link operation couples the resource identifier with the actor. The details endpoint filters by both short_url and user_id in one query; deletion adds a second predicate (the user id) to the delete; the dashboard listing filters clicks by the link id of links already scoped to the user; monitor-key routes filter by the SHA-256 digest of the provided key, which has 256 bits of entropy; and the dashboard analytics page resolves the user first and passes the user id as the scope. Unauthenticated access returns 401; authenticated-but-not-owner requests resolve to the same generic 404 ("Link not found or unauthorized"), so existence is not disclosed. Finally, getMonitorPayload() and the listing routes scrub sensitive columns - password and monitor_key are deleted from every serialized response and replaced at most with a boolean is_protected flag.

Because the service-role client spans the redirect path, both auth providers, and anonymous creation, enabling RLS would mean maintaining a second, per-request auth context for one pool of tables and duplicating every application rule in Postgres policies. Keeping authorization in the query layer means the rule lives next to the data access it protects, in one codebase and one review path. The 404-for-non-owners semantics prevent both existence leakage and enumeration of the identifier space, at the cost of a slightly less informative error - a cost worth paying for a public shortener.

Shortening works without an account, so an anonymous link has no user_id to scope ownership to - yet its creator still needs the two management powers: reading analytics and deleting the link. The easy answers are fatal: storing the management secret in plaintext makes a database read equivalent to taking over the link, and a per-account wall destroys the anonymous flow that is the product's primary path. What is needed is a bearer capability - a secret the creator possesses, that the database does not, granting exactly two powers over exactly one link, forever.

createShortLink() derives a 64-character monitor key from the same crypto.randomInt primitive used for sessions, persists only its SHA-256 digest in links.monitor_key, and returns the plaintext exactly once - inside the redirect_url of the shorten response (/{short_url}/{monitor_key}). Anonymous clients keep the key in localStorage through the "Recently Shortened" panel, where every entry renders an Analytics link that carries it. GET /:short_url/:monitor_key hashes the presented key and scopes the entire payload query to that digest; the route content-negotiates on Accept, serving browsers a full server-rendered analytics page - link card, total and unique clicks with today-vs-yesterday deltas, expiry and click-limit status, a Chart.js clicks-over-time chart, and a per-click table of time, country, OS, and referrer domain - and API clients the same data as JSON. DELETE /api/v1/:short_url/:monitor_key couples short_url with the key digest in a single delete. Logged-in owners reach the same page through /dashboard/analytics/:short_url, scoped by user_id instead; monitor-route scope failures return the same "Link not found or invalid monitor key" 404, and the dashboard analytics page answers a miss with its own 404 page - either way a non-owner never learns whether the link exists. Password and monitor_key columns are scrubbed from every payload and replaced by an is_protected boolean, and the timestamps embedded into the chart script are JSON-escaped with < rendered as \u003c so stored data can never break out of the inline script.

The capability design inverts the database's value: because the plaintext key is issued once and never stored, possession of the database - even the service-role path itself - is insufficient to manage a link, and a leaked key is a capability rather than a credential: it cannot authenticate anywhere and its dual-predicate queries stop it from working on any other link. Content negotiation gives one endpoint to humans and machines without maintaining two management APIs, and routing logged-in owners through the same page keeps the anonymous and authenticated management surfaces from drifting apart.

The public surface of a shortener is a brute-force target: login and registration are guessable-credential endpoints, the shorten endpoint can be hammered into a link-spam factory, and QR generation can be driven as an image-request amplifier. But the mitigation has to survive the architecture: this runs on Workers, where memory is per-isolate, and the response must stay sub-millisecond on the redirect path. It also has to be sane for real users - an uptime monitor polling health never deserves a 429, and a rate-limited visitor hitting a password-protected link should still receive a coherent unlock page, not a bare JSON body.

A fixed-window limiter keeps a Map of (method, path, client IP) buckets reset every 60 seconds, with the client IP taken from the first entry of x-forwarded-for before falling back to x-real-ip. The middleware accepts a per-route ceiling: login/register run at the 10/min default, QR generation at 10/min, profile reads at 120/min, and the shorten endpoint differentiates by auth state - 10/min anonymous, 20/min when a sid cookie or Bearer token is present, doubling the quota with a message that explicitly markets registration. When a bucket is exhausted the middleware negotiates the response by request shape: a POST to a single-segment path re-renders the password-unlock form with the 429 embedded as a warning, HTML GETs outside /api get a branded "Rate Limit Exceeded" page, and API clients receive structured { status, reason } JSON. The health endpoints are deliberately registered without the middleware so monitoring probes are never throttled.

An in-memory fixed window costs zero external I/O on the hottest path in the system - the redirect - whereas a shared KV or Durable Object counter would add a storage round-trip to every single hit, including 302 responses that should cost nothing. Per-route ceilings and auth-aware quotas make the limiter a business policy, not just a flood valve: it caps credential guessing while doubling the shorten budget for signed-in users, and it keeps the QR endpoint at a cost level that cannot be abused as a request amplifier. The honest trade is that memory-local buckets are per-isolate, so this layer is defense-in-depth rather than a global cap - it is fast, free, and always on, and the edge platform's own protections remain available above it.

The shorten payload is a small state machine, not a flat form: type is random or alias; alias exists only for alias mode but then must be 5-15 alphanumeric, must not collide with roughly 430 reserved words covering routes, platform paths, and brand names, and must pass a profanity dictionary; isLimited forces the choice of a limitation type, time-limited links demand expires_in, click-limited links demand max_clicks; isProtected demands a password meeting four character-class rules. Validation bugs here poison the entire namespace - an alias squatting a reserved route breaks the site itself - and a payload-shaped hole lets clients inject fields the business logic never intended to accept.

The entire contract lives in one zod schema: a base object of typed fields (url, type, isLimited, isProtected, plus optionals) refined by a superRefine pass that encodes the cross-field invariants - alias requiredness and format, the reserved-word and profanity checks, the limitation_type/expires_in/max_clicks dependency chain, and the full password-complexity rule set. Zod strips unknown keys by default, so extra client fields never reach the handler, and the first validation issue is extracted and returned to the client as a single human-readable detail string. Alias creation additionally pre-checks the database for a duplicate and maps unique-constraint violations from the insert into the same "alias already taken" response; random mode retries generation against the unique constraint up to 1,000 attempts, so a 5-character code drawn from a 62-character alphabet self-heals through collisions instead of failing a request.

One schema beats scattered if-chains because the conditional dependencies are explicit and tested as a unit - the alternative of two schemas (alias vs random) would duplicate the isLimited/isProtected branches and drift apart during maintenance. The retry loop exists because the unique key is DB-enforced: the check-then-insert race between two simultaneous requests with the same random code is resolved by the constraint itself, and the loop turns that race into a retry instead of a 500. Putting the reserved-word list into a single compiled regex keeps the namespace policy enforceable at the same place where aliases are accepted, so a route added later propagates into the filter by list edit alone.

A URL shortener is the canonical surveillance instrument: every redirect passes through the service, and a naive implementation would store raw visitor IPs, full user agents, and exact referrers - a perfect re-identification kit for the people clicking shortened links. The second constraint is performance: analytics capture sits on the single most latency-sensitive path in the system, the 302 itself, and an awaited database write per click would tax every redirect. The analytics must still answer real questions: how many distinct visitors, from which countries, through which referrers, on which platforms.

The pipeline minimizes data before it touches storage. At redirect time the client IP is immediately hashed with hashIp() - SHA-256 over a SALT-wrapped value - so no raw address is ever written; the user-agent string is run through UAParser and reduced to its OS name only, discarding the raw string; the referer is matched against a curated table of known sources (search engines, social networks, LLM platforms, chat apps) and falls back to the bare domain; and the country comes from Cloudflare's cf-ipcountry edge header, which clients cannot spoof. Telemetry is then fired with executionCtx.waitUntil(), so the Worker returns the 302 immediately and keeps the isolate alive only long enough to finish the asynchronous write; the write itself is wrapped in a try/catch so a failing insert can never break a redirect. Unique-click counts are computed in the application layer as the size of a Set of distinct ip_hash values per link, and the details endpoint aggregates referrers, countries, browsers, OS, and a per-day timeline from the stored click rows.

Hashing the IP before storage means the database contains no personally-recoverable address at any point in the pipeline - uniqueness is preserved as a first-class metric without the data that would make it a tracking device. Reducing the user agent to a parsed OS name gives platform breakdowns while eliminating device fingerprinting. The fire-and-forget logging pattern is the only way to keep telemetry on a redirect path: the client sees the 302 as soon as the counters are read, and the write completes in the background or is dropped on failure. Alternatives like pushing clicks through a queue or a second worker add infrastructure and ordering complexity to a service whose entire value is a fast redirect.

The write path minimizes data before storage, but the product has to present that data: per-link detail pages, dashboard aggregates, and breakouts by referrer, country, browser, and OS - all derived from rows in which the IP exists only as a salted hash and the user agent only as an OS name. The distinct-visitor metric has to survive the minimization: with raw IPs gone, "unique visitors" must be computed from the hashes themselves, and the same counting semantics must hold everywhere the number appears - the details API, the dashboard, and the monitor page - or the product starts reporting three different truths.

The details endpoint loads the link with a dual scope (short_url plus user_id) and aggregates its click rows in the application layer: total clicks is the row count, unique clicks is the size of a Set over the ip_hash values, referrers are grouped by extractDomain(), countries by the stored value, browsers and OS by re-parsing the stored user-agent column, and a per-day timeline is built by keying ISO dates. /api/v1/my-links applies the same Set computation per link so the dashboard can render each card with its unique count, then the dashboard client computes today-vs-yesterday deltas for clicks, unique clicks, and links created, tallies protected, limited, and expired links, draws a Chart.js area chart of clicks per day, and supports sorting (newest, oldest, most and least clicked, expired) with five-link pagination. The monitor page renders the same aggregations server-side, sharing the identical Set-based counting logic.

Computing uniqueness as the size of a Set over salted hashes is the only faithful way to estimate distinct visitors once raw IPs are gone, and it keeps the privacy property intact end-to-end: the value that measures a visitor is the same value that cannot identify them. Keeping aggregation in application code instead of SQL window functions means one implementation serves the API, the dashboard, and the monitor page - a SQL rewrite would fork the counting semantics across three surfaces and they would silently drift apart.

The application is server-rendered HTML with inline scripts, pulls Chart.js and the Supabase browser SDK from a CDN, connects to Supabase and Google Fonts from different origins, and embeds visitor-derived values in pages. Default behavior would ship pages with mixed-content risk, MIME-sniffing ambiguity, no clickjacking protection, and permissive referrer leakage - and the fix has to survive a codebase where a new page handler is added every few weeks without remembering to harden its own headers.

A single app.use("*") middleware runs after every handler and stamps headers onto every response the Worker emits. The Content-Security-Policy explicitly allows only what the app actually consumes: "self", inline scripts and styles (the templates are inline by design), scripts from cdn.jsdelivr.net, Google Fonts and Font Awesome style/font origins, https: images, and connect-src limited to "self" and https://*.supabase.co - while blocking object-src, constraining base-uri, forbidding frame ancestors, and limiting form-action to "self", which pins the password-unlock POST to the same origin. Strict-Transport-Security is set with includeSubDomains and preload, X-Content-Type-Options: nosniff and X-Frame-Options: DENY are set alongside the CSP frame-ancestors block, Referrer-Policy is strict-origin-when-cross-origin, and Permissions-Policy strips camera, microphone, geolocation, payment, usb, and accelerometer access. Cross-Origin-Opener-Policy: same-origin, Cross-Origin-Resource-Policy: same-origin, and Origin-Agent-Cluster round out the isolation set.

Hardening in one middleware means a new route cannot forget its headers - the policy is structural, applied after the response exists, so even an error response from the notFound handler gets the same treatment. The CSP is written as an explicit allowlist of what the current build actually loads, which is what makes it enforceable: the CDN entries exist only because Chart.js and the Supabase SDK are loaded from jsdelivr, and form-action: "self" exists because the password-gate form is the only server-rendered form target in the system. The double clickjacking defense (CSP frame-ancestors plus X-Frame-Options) covers both CSP-aware and legacy user agents, and upgrade-insecure-requests converts any accidentally http-served asset into https before it reaches the network.

A shortened URL is a fully public endpoint: anyone can hit it, and it must enforce link-level policy on every single hit - expiration dates, click quotas, and protection passwords - before disclosing the destination or recording telemetry. A naive redirect would reveal the long URL before checking anything, count failed unlock attempts as legitimate clicks, and allow refresh-safety bugs that double-count or replay submissions through the password form.

GET /:short_url runs a fixed order of gates. It resolves the link record, returns the generic 404 page when the alias does not exist, checks expires_at against the current time and the stored click counter against max_clicks - an exhausted link gets a 410 Gone page, not a redirect - and only then checks whether a password is set; if it is, the response is the unlock form, and the long URL is never part of that page. Only when every gate passes does the route derive the analytics fields and fire the mid-flight telemetry, then answer 302 to the destination. The unlock path mirrors the same gates: POST /api/v1/:short_url parses the form, re-checks expiry and quota, verifies the password against the stored digest, rejects failures with a 403 re-rendered form, and on success logs the click and answers 303 See Other - the post-redirect-get status - so refreshing the browser window replays a GET to the destination instead of re-submitting the form and double-counting. Failed password attempts return 403 without recording a click, and both routes share the rate limiter, whose 429 response is itself the unlock form with an embedded warning.

Ordering the gates before any redirect guarantees that expired or quota-exhausted links never leak access at all, and that protected destinations are never disclosed to unauthenticated clients. The 303 after a successful unlock is the HTTP-correct answer for "a form POST produced a resource": the follow-up GET is what a refresh re-executes, so accidental resubmission cannot inflate click counts or log phantom visits. Keeping one code path (and the same gate helpers) between the GET and POST branches prevents the two flows from drifting apart in policy behavior - both refuse what the other refuses.

Every shortened link deserves a scannable, downloadable QR code, generated on the landing page at creation time and on demand from the dashboard. But the endpoint is a natural abuse vector - QR rendering is synchronous CPU work an attacker can drive as an image-request amplifier - and the alternative of a third-party QR API would ship every encoded URL to an external service, exactly the data-sharing the privacy pipeline exists to prevent.

GET /api/v1/qr?url=... renders the PNG synchronously at the edge with qr-image (size 10, margin 2, parse_url enabled) - no external QR service, no client-side library. The route sits behind the same fixed-window limiter with a dedicated ceiling of 10 requests per minute per client, returns 400 for a missing url parameter, and answers render failures with a sanitized 500 that leaks no internals. Every successful image is stamped Cache-Control: public, max-age=31536000, immutable: because the encoded URL is part of the request, the URL is the cache key, so repeat scans are served from cache at zero worker cost. The landing page fetches the endpoint into an <img> right after shortening with a download link, and the dashboard opens the same endpoint in a per-link modal.

Rendering at the edge keeps QR generation inside the request lifecycle with zero external dependencies, and keeps encoded URLs inside the first-party boundary - the privacy guarantee holds because no visitor URL ever leaves the Worker. The fixed 10/min ceiling makes the endpoint unprofitable as a request amplifier, and the immutable cache turns the most common cost - identical repeated scans - into a permanent cache hit.

The registration surface was hardened at creation time, but the same fields remain editable: full name, username, and password. Each edit re-opens the validation surface, and the username change carries a subtle hazard - the credential digest is deterministically bound to the username, so renaming without re-deriving the digest would silently lock the user out at the next login. Separately, sessions die all the time - rotation, expiry, deletion - and a half-logged-in client left behind is a ghost identity: stale Supabase tokens and orphaned localStorage that keeps greeting a user who no longer exists.

POST /api/v1/profile applies the exact registration regexes to every provided field, and username changes run a uniqueness query that excludes the current user id - renaming to your own username is a no-op, colliding with another user is a 409. A password change re-derives the digest as formatWithSalt(newUsername) concatenated with formatWithSalt(newPassword) - the same derivation login uses - so the stored auth stays coherent after the identity component of the digest changes; the full name is re-capitalized and updates merge into a single UPDATE scoped by user id. GET /api/v1/profile resolves either provider and returns provider-appropriate fields (Google email, picture, and name; custom username and full name). On the client, every page that displays auth state probes /api/v1/profile on load, and a 404 - a user who no longer exists - triggers a full teardown: Supabase signOut, the sid cookie expired, localStorage wiped except the consent flag and the link-history panel, then a redirect home.

Reusing the registration regexes means the update path can never relax a rule the create path enforces - one vocabulary of credential rules across the whole identity surface. Re-deriving the digest on rename is not defensive extra credit, it is what keeps the deterministic hash scheme consistent after its username component changes. The load-time probe turns an invisible dead session into an explicit clean sign-out, and it is precisely why the cookie can afford to be JS-readable: the client is trusted to observe the source of truth and clean up after itself when the session is gone.