theme-events-ticketing

name	theme-events_ticketing
description	Events / ticketing application palette: variants, pages, entities, and flows for building a varied ticketing app. Use when theme_preset is events_ticketing.

Events ticketing theme

Domain

Apps that sell limited tickets against an event's capacity. The invariants that matter — a seat is sold once, a ticket is valid for one entry, a discount fires on the right rules, you only see your own tickets — are exactly where the interesting exploits live.

Application variants — pick ONE per lab

Honor any hint in theme_free_text / custom_prompt; otherwise pick one.

• Concert / festival — general-admission tiers, day passes, add-ons.
• Cinema seating — showtimes, seat map per screen, concessions.
• Conference passes — pass tiers, sessions, schedules, attendee badges.
• Sports season tickets — fixtures, seat sections, season vs single-game.
• RSVP / free events — capacity-capped registrations, waitlists, check-in.

Roles — choose the set that fits the variant

• user (attendee) — browse events, buy/RSVP, view own tickets, transfer.
• service — capacity/availability sync, hold-expiry jobs where relevant.
• admin (organizer) — create events, scan tickets, refunds, attendee lists.

Most exploits run as user.

Candidate pages — select a coherent subset

Size the subset to endpoint_count. Candidates: events list, event detail, seat/section map, ticket-tier selection, cart & checkout, order confirmation, my tickets, ticket detail / QR code, transfer or resell a ticket, request a refund, profile/settings, notifications, organizer events, scanner / check-in, attendee list, admin refunds.

Candidate entities (seed tables) — select what the variant needs

• users — id, email, password_hash, role
• events — id, title, venue, starts_at, capacity, status, organizer_id
• ticket_tiers — id, event_id, name, price_cents, quota, remaining
• seats / sections (seated) — id, event_id, label, section, status
• orders — id, user_id, event_id, total_cents, status, created_at
• tickets — id, order_id, tier_id, seat_id?, holder_id, code, status
• holds — id, user_id, seat_id/tier_id, expires_at
• discounts — id, code, kind, value, max_uses, used, event_id?
• refunds — id, ticket_id, amount_cents, status, requested_at
• checkins (organizer) — id, ticket_id, scanned_at, gate

Seed multiple attendees each with ≥2 tickets across events so cross-account and transfer exploits are possible.

Candidate user flows — select the ones matching chosen pages/features

1. Browse events → open one → pick a tier/seat → checkout → confirmation.
2. Select a seat from the map → it's held, then issued as a ticket.
3. Apply a discount code at checkout → total recomputes.
4. Open my tickets → view the QR / barcode for entry.
5. Transfer a ticket to another attendee (or list it for resale).
6. Request a refund on an order → status updates → ticket voided.
7. (organizer) Create an event with tiers → publish → watch sales.
8. (organizer) Scan a ticket at the gate → it's marked used; a second scan fails.

Candidate endpoints — a feature may span several

Endpoints are a shared surface, not owned 1:1 by a feature (a single feature often spans several, and an endpoint can back multiple features). Pick a coherent subset alongside the pages above. Grouped by area:

• events — GET /api/events, GET /api/events/{id}, GET /api/events/{id}/seats
• checkout — POST /api/holds, POST /api/orders, POST /api/orders/{id}/pay, POST /api/orders/{id}/discount
• tickets — GET /api/tickets, GET /api/tickets/{id}, GET /api/tickets/{id}/qr, POST /api/tickets/{id}/transfer
• refunds — POST /api/orders/{id}/refund, GET /api/refunds/{id}
• organizer — GET/POST /api/admin/events, POST /api/admin/events/{id}/publish, GET /api/admin/events/{id}/attendees
• scanner — POST /api/admin/checkin, GET /api/admin/checkin/{ticket_code}

Where vulnerabilities fit naturally

• race_condition → two buyers hold/purchase the last seat or the last unit of a quota concurrently; redeem a single-use discount twice.
• business_logic → discount past max_uses, stack/duplicate codes, refund more than paid, buy above the per-order limit, negative quantity.
• idor → GET /api/tickets/{id} / /api/tickets/{id}/qr — read or screenshot another attendee's ticket/QR; transfer someone else's ticket.
• auth_bypass → reach the organizer scanner or attendee list without a valid organizer session; validate a forged ticket code.
• privilege_escalation → attendee reaching /api/admin/... organizer actions.

Diversity guidance

Pick ONE variant and a coherent subset — a cinema seat-map app and a free-RSVP app should not share a page list. Size to endpoint_count; let theme_free_text / custom_prompt bias the variant and naming. Vary venue types, tier structures, and seating vs GA so two ticketing labs feel like different platforms.