Marketplace Project: Secure the Marketplace

Start from accepted milestone 26. Use the shared project reference for setup, contracts, isolated checks, and submission.

Receive the authentication contribution

After milestone 26 passes, receive the supplied authentication modules, migration 005, API test helper and lifecycle suite, docs/authentication.md, and tools/prepare-authentication.mjs through Git:

git fetch origin
git diff HEAD..origin/milestone-27
git merge --ff-only origin/milestone-27

Commit unfinished local edits before merging. If local commits prevent a fast-forward, inspect the contribution and use git cherry-pick origin/milestone-27, preserving your work. If a supplied path already exists, compare and resolve that file without replacing your application. The contribution leaves your application routes, resource implementations, configuration and lockfile intact.

Follow docs/authentication.md to preview and apply the dependency addition using the existing client container, then refresh api/deno.lock with that runtime. The helper preserves your other configuration values and can be rerun safely. Review git diff; rebuild the API image after updating the lockfile.

Objective

Integrate the supplied authentication subsystem with the marketplace. It contains complete credential verification, persistent sessions, cookie handling, origin/CSRF middleware, and bounded abuse controls.

Keep these supplied implementations; this milestone assesses how application requests use them.

1. Apply the supplied migration 005 in isolated storage; do not rewrite migrations 001-004. Existing seed users have no password and cannot log in; create synthetic test accounts through the supplied registration route.

2. Turn Part 4’s singleton publicApi and app setup into createBrowserApi and createApp factories using the steps in docs/authentication.md. Construct one createSecurityBoundary(cookieName) per app and connect its auth routes, actor resolver and supplied request middleware to the existing resource route chain. Preserve the handlers and inferred AppType for #api. Keep the ordinary app export and existing entry point.

   Configure the exact UI origin, credentialed CORS, and the documented cookie settings. Remove development-identity middleware and header fallbacks.

3. Use the resolved actor ID for draft creation, seller reads and bids. Call security.withBidLimit(actorId, operation) around bid work and pass security.allowAuthAttempt to the supplied auth router; these controls are supplied and ready to use. Resource ownership checks follow in milestone 30.

4. Replace the development identities in your existing draft-creation, draft-edit and bid-HTTP test fixtures with authenticated test accounts. The contribution supplies api/tests/helpers/authenticated-account.ts; retain your tests’ assertions and cleanup. Input-rejection tests need valid session/origin/CSRF context so they reach the existing input rules; missing or non-JSON Content-Type still gives 400 INVALID_INPUT. Run the supplied lifecycle suite to check that a forged development header cannot identify a caller and that rejected requests leave storage unchanged. It also covers missing/incorrect CSRF tokens.

Supplied boundary and application work

The supplied migration adds only account credential state and sessions. A safe user is {id,displayName}. The session contract documents the existing login, registration, session and logout endpoints.

Keep the existing resource schemas, SQL repositories, transaction logic and Hono RPC inference. Modify api/src/app.ts and api/src/routes/public-api.ts to connect the boundary. Use the supplied protectSessionRequests middleware; do not reproduce cookie parsing, session storage or password algorithms in resource handlers. Write PERMISSION-MATRIX.md from the five-row shared matrix as the target for milestones 30-31.

Test and submit

Run the three updated inherited API test files, followed by the complete API suite against the isolated database. The contribution includes api/tests/supplied_session_lifecycle_test.ts; keep it unchanged. The ordinary suite discovers it, or run it directly with deno test --no-check --allow-env --allow-net tests/supplied_session_lifecycle_test.ts using the shared API Compose command. It checks successful login/session resolution, logout, expiry and request protections. Keep existing successful resource mutations working with the correct session, origin and token.

Type checking remains useful for the inferred route contract and is optional for points. Submit the integrated source, supplied files, migration, lockfile and updated tests.

Points

• 25 points: registration, cookie sessions and current-user reads establish trusted identity; a development header cannot impersonate an account.
• 20 points: protected resource mutations enforce the supplied origin/CSRF and JSON-input checks, while valid requests still succeed.
• 15 points: expiry, disabled/deleted accounts and logout preserve the supplied session lifecycle contract.
• 10 points: the three updated inherited API tests pass and the permission matrix records the target policy.

These groups assess the existing integration separately.

Start from accepted milestone 27. Use the shared project reference for repository setup, contracts, isolated checks, and submission.

Receive the account setup

After milestone 27 passes, receive the milestone 28 contribution in your accepted marketplace repository:

git fetch origin
git diff HEAD..origin/milestone-28
git merge --ff-only origin/milestone-28

Commit unfinished local edits before merging. If local commits prevent a fast-forward, inspect the contribution and use git cherry-pick origin/milestone-28, preserving your work. If a supplied path already exists, compare and resolve that file without replacing your application or tests. The contribution supplies:

• client/src/lib/supplied/session-client.ts
• tools/migrate-session-test-fixtures.mjs
• docs/account-workflow.md

Objective

Connect the accepted server session API to the browser. The supplied module handles the CSRF plumbing; implement the typed account operations and interface.

The browser stores and sends the HttpOnly session cookie; JavaScript cannot read it. The browser also creates the Origin header. The supplied helper includes credentials, stores the separate CSRF token returned by /api/session, and sends that token on mutations. Keep passwords out of persistent browser storage.

Follow docs/account-workflow.md to connect createSessionFetch(options) to both your Hono client and existing fetch-based requests. Preserve status checks, read decoders, and rejection feedback. Stop sending development identity headers. Infer successful response types from #api.

Implement the typed operations in client/src/lib/api/auth-api.ts. For example:

const readSession = async () => {
  const response = await createTypedMarketplaceClient().api.session.$get();
  if (response.status !== 200) return await accountFailure(response);
  return await response.json();
};

Use your structured API error handling in accountFailure, preserving HTTP status, code, and message. Give it the signature const accountFailure = async (response: Response): Promise<never> => { ... };: Promise<never> tells TypeScript that the helper throws instead of returning a successful value.

Registration accepts { email, displayName, password } and returns JSON on 201; login accepts email, password and returns JSON on 200.

Logout accepts the supplied transport, calls createTypedMarketplaceClient({ transport }).api.auth.logout.$post(), and expects 204 without decoding JSON. Bind these operations once:

import { createAccountClient } from "#lib/supplied/session-client.ts";

export const { getSession, register, login, logout } = createAccountClient({
  session: readSession,
  register: registerAccount,
  login: loginAccount,
  logout: logoutAccount,
});

Render client/src/lib/components/Account.svelte at /account. Import the supplied accountState readable store, call getSession() on startup, and render its unknown, anonymous, and authenticated states. The authenticated state contains user.id and user.displayName. Use the returned client methods for registration, login, and logout; session refresh and token cleanup are supplied. Show pending feedback and errors.

Registration does not log in; tell the user to log in after success.

Use labels Email, Display name, and Password; buttons Register, Log in, and Log out; Account created feedback; and Signed in as NAME for the current account. Follow the shared session responses and errors.

The next milestone connects the seller and bidding screens to this account state and updates the existing browser journey. Their development actor controls and existing caller arguments can remain until then; the server already derives identity exclusively from the session, and the shared transport no longer sends a development identity header.

Preserve the existing client fixtures

From marketplace/, preview and apply the routine fixture changes:

docker compose -p wsd-marketplace-test -f compose.yaml -f compose.test.yaml run --rm --no-deps \
  --volume "$PWD:/workspace" --workdir /workspace client deno run --allow-read=client \
  tools/migrate-session-test-fixtures.mjs
docker compose -p wsd-marketplace-test -f compose.yaml -f compose.test.yaml run --rm --no-deps \
  --volume "$PWD:/workspace" --workdir /workspace client deno run --allow-read=client \
  --allow-write=client tools/migrate-session-test-fixtures.mjs --write

Review git diff. The helper preserves the existing assertions while replacing development identity with credentials and session fixtures. It also adapts already-migrated fixtures to the supplied session module. It can be rerun safely and stops without writing if it cannot recognize a fixture. Keep your tests and ask for an adapted migration in that case.

Focused checks and points

Run the existing client check, test, and build tasks. deno task check includes the typed auth client. Type checking is optional for points. Manually verify registration, login, a session read after a page reload, and logout on /account. Keep the accepted API tests passing. The inherited marketplace browser journey is adapted and assessed next.

• 20 points: registration uses the typed client, sends the account fields, shows success feedback, and leaves the visitor signed out.
• 20 points: typed login, session reads and logout keep the displayed account and supplied session context consistent.
• 20 points: the shared transport connects the supplied credential and CSRF helpers, including read-only requests and cleared account state.

These groups award points independently after a successful client build.

Start from accepted milestone 28. Your account controls and shared transport now use server sessions. Use the shared project reference for contracts, checks, and submission.

Receive the browser setup

After milestone 28 passes, receive tools/browser-proxy.ts, compose.browser-tests.yaml, and docs/authenticated-marketplace.md through Git:

git fetch origin
git diff HEAD..origin/milestone-29
git merge --ff-only origin/milestone-29

Commit unfinished local edits before merging. If local commits prevent a fast-forward, inspect the contribution and use git cherry-pick origin/milestone-29, preserving your work. Compare and resolve any supplied path that already exists without replacing your application or tests. These files provide the browser-test topology, not completed screens.

Objective

Connect the existing seller and bidding screens to the shared account state. Resolve the session when entering a protected workflow, show sign-in guidance when anonymous, and use the confirmed account when rendering available actions. The API remains responsible for authorizing every request.

Remove browser development actor selectors, caller arguments and the obsolete actorId API option. Keep client/src/lib/schemas/draft-schema.ts focused on editable draft fields; account identity does not belong in its validated form data.

Use the shared credential and token transport from milestone 28 for marketplace requests. Preserve pending and rejection feedback, retained form input, and the existing explicit conflict-reload behavior.

The fixture migration from milestone 28 already supplies session reads for the existing client tests. Keep their assertions and use those fixtures with the connected screens.

Complete the existing browser journey

Use the supplied browser test topology. Merge the documented Vite allowed hosts into your existing configuration, preserving other settings, and preserve an empty API base with ?? and full /api/... paths. The Compose override supplies the exact browser-visible origin; docs/authenticated-marketplace.md gives the run and shutdown commands.

Adapt e2e-tests/tests/student_mutations.spec.ts to register and sign in the seller, create/publish the listing, then log out and register/sign in a different buyer before bidding. Keep the existing mutation and rejection coverage.

Focused checks and points

Run client check, test, and build tasks. Type checking is optional for points. Run the authenticated inherited browser suite through the isolated proxy topology and verify seller draft creation/publication, logout, and the different buyer’s bid. Keep the accepted account controls and API checks passing.

• 40 points: the built marketplace uses the current account and completes the authenticated mutation workflow against the real API.
• 20 points: the same passing journey asserts the buyer’s accepted bid and detects an incorrectly rejected bid, retaining its existing rejection assertions.

The assertion group uses the existing journey and requires that journey to pass against the working application. The workflow behavior is assessed independently of the submitted test’s assertions.

Start from accepted milestone 29. Use the shared project reference for contracts and isolated checks.

Continue after milestone 29

After milestone 29 passes, continue on master in your accepted marketplace/ repository. Before starting this milestone or submitting, run:

git fetch origin

Fetching prepares milestone 30 for grading and makes its optional previous-step reference at origin/milestone-30 available. It does not change your working files. You do not need to merge the reference to complete this milestone.

Objective

Apply the draft rules from the permission matrix at the service boundary. Only a draft’s seller may edit, publish or delete it. Check ownership in the same locked transaction as resource state and version.

Public collection reads omit drafts; a signed-in seller can read their own draft through the detail route, while another caller receives 404. The caller ID always comes from the resolved session.

Keep the supplied request and abuse controls in place. Milestone 31 adds the separate bidding permission rule.

Files and test evidence

Modify api/src/services/listing-service.ts, api/src/routes/public-api.ts, api/src/repositories/listing-repository.ts and api/src/repositories/draft-repository.ts as needed. Include seller_id in the locked draft row so the service can check its owner.

Add FORBIDDEN to ResourceError in api/src/services/marketplace-errors.ts and map it to the documented 403 response.

Create api/tests/student_authorization_test.ts with one focused owner/outsider edit comparison (an awaited t.step inside a Deno.test is sufficient).

Use the supplied authenticated-account helper for an owner and another account. First send a valid owner PATCH, assert 200 and inspect its stored title and incremented version.

Then send a different proposed title as the outsider, with that account’s valid session, correct Origin, matching CSRF token, valid body and the current version. Assert 403 FORBIDDEN and immediately compare stored title/version with their values before this request. These observations distinguish a permitted edit from an unchanged response, and a rejected edit from a handler that writes before returning 403.

Keep test-owned accounts and resources, and clean them up explicitly. Reuse this file for the bidding comparison in milestone 31.

Use test-owned active listings in the inherited relationship-read regression because public browsing now excludes seeded drafts. Preserve its related seller/category assertions and explicit cleanup.

Test and submit

Run docker compose -p wsd-marketplace-test -f compose.yaml -f compose.test.yaml run --build --rm api deno test --no-check --allow-env --allow-net tests/student_authorization_test.ts, then the complete isolated API suite. Type checking is optional for points.

Points

• 55 points: ownership and listing visibility are enforced at the authoritative operation.
• 20 points: the owner/outsider comparison checks both the response and stored state, detecting a blocked owner, an allowed outsider or a write before rejection.

The implementation is checked independently. The comparison points require the submitted integration suite to pass and detect the stated faults. Denied draft writes give 403 FORBIDDEN; missing or concealed detail reads give 404 NOT_FOUND.

Start from accepted milestone 30. Use the shared project reference and keep milestone 29’s browser test topology.

Continue after milestone 30

After milestone 30 passes, continue on master in your accepted marketplace/ repository. Before starting this milestone or submitting, run:

git fetch origin

Fetching prepares milestone 31 for grading and makes its optional previous-step reference at origin/milestone-31 available. It does not change your working files. You do not need to merge the reference to complete this milestone.

Add the bidding permission rule

Prevent a seller from bidding on their own listing. A different signed-in buyer can bid when the existing amount/deadline rules allow it.

Check the listing’s seller against the caller ID from the resolved session in the same locked transaction as the existing bid rules, before changing auction state.

Modify api/src/services/auction-service.ts and api/src/repositories/auction-repository.ts as needed, and map the new FORBIDDEN result through api/src/services/bid-rules.ts and api/src/routes/public-api.ts. A rejected self-bid returns 403 FORBIDDEN without changing price, version or bid rows. Keep the supplied request and abuse controls in place.

Extend the existing authorization check

Keep milestone 30’s owner/outsider edit comparison in api/tests/student_authorization_test.ts. Add a second focused comparison to the same file: assert that a self-bid returns 403 FORBIDDEN and inspect the unchanged price, version and bid rows, then assert 201 for a different signed-in buyer’s valid bid and check that it was stored.

Both comparisons may share one Deno.test, with or without separate awaited t.step cases.

Use the supplied authenticated-account helper, test-owned accounts and resources, and explicit cleanup. Both requests need valid session/origin/CSRF context and input so they reach the bidding rule. Reuse the existing file and fixture approach.

Finish the integration

Milestone 27’s Git contribution already supplied api/tests/supplied_session_lifecycle_test.ts. Keep that file unchanged in the cumulative repository.

Keep the earlier stale-version, bid and concurrency suites. Reuse e2e-tests/tests/student_mutations.spec.ts from milestone 29: its seller-publication/buyer-bid journey exercises the connected cookie workflow.

Test and submit

Run the focused api/tests/student_authorization_test.ts, then the complete isolated API suite, which discovers both authorization comparisons, the supplied lifecycle file and earlier regressions. Run the accepted browser journey and client build using the shared project commands.

Submit the cumulative repository with those existing files. Type checking remains useful and optional for points.

Points

• 20 points: self-bids are rejected without changing auction state, a permitted buyer can still bid, and the submitted comparison detects an incorrectly accepted self-bid.
• 10 points: the supplied lifecycle and retained stale-version, bid and concurrency API suites pass independently of the new comparison.
• 10 points: the accepted real-cookie two-account browser workflow still completes.