read.markets/tests/test_pending_cookie.py
Giorgio Gilestro 9759080134 phase D milestones 1+2: referral system + paid-access gate
Lays the billing-prep spine before Paddle lands in D.3.

D.1 — referrals
- users.referral_code: unique 8-char URL-safe code (alphabet excludes the
  ambiguous 0/O/1/I/L). Generated lazily on first /settings hit so existing
  accounts pick one up without a backfill migration.
- users.referred_by_user_id + new referrals audit table (referrer,
  referred, created_at, converted_at, credited_at). converted_at /
  credited_at stay null until D.3 fills them via the Paddle webhook.
- POST /login accepts ?ref=<code>; the code rides on the signed
  pending-verify cookie so it survives the GET → POST → /verify hop.
- /settings page: email, tier badge, referral code chip + invite link
  with one-click copy, pending/converted/active-credits stats grid.
  Settings nav link added to the top bar.

Reward shape: when the referred user makes their first paid Paddle
subscription, both they and the referrer get 50% off for 3 months.
(D.3 wires the actual credit application via the Paddle webhook.)

D.2 — paid-access gate
- users.credit_until: timestamp until which a free-tier account has
  paid-tier access. Null = no credit. Populated by admin CLI now and the
  D.3 webhook later.
- app.services.access exposes paid_status(user) → PaidStatus dataclass
  (active / source / expires_at / days_remaining), is_paid_active() with
  admin-bearer-token bypass, and a require_paid FastAPI dependency that
  raises 402 Payment Required for free-tier callers.
- POST /api/analyze (portfolio AI commentary) gated behind require_paid.
- Settings page surfaces credit window when active ("free · credit · N
  day(s) remaining (expires YYYY-MM-DD)") and the upgrade hint when not.
- Admin CLI: python -m app.cli {grant-credit,revoke-credit,show-status}.
  grant-credit is idempotent — extends from max(now, current expiry) so
  re-running the command never erodes an existing grant.

Migrations 0013 (referrals) and 0014 (credit_until). Tests cover the
paid-status truth table, code generation + normalisation, CLI argument
parsing, and the pending-cookie ref roundtrip (29 new tests).
2026-05-21 23:25:35 +01:00

42 lines
1.7 KiB
Python

"""Sign/verify roundtrip for the short-lived pending-verification cookie.
The pending cookie carries the email + user_id under verification. It is
NOT an auth cookie — never grants access beyond /verify and /verify/resend
— so the only properties we test are: round-trips correctly, rejects bad
signatures, and the salt is distinct from the session cookie's so a session
cookie can never be mistaken for a pending cookie."""
from __future__ import annotations
from app import auth
def test_pending_cookie_roundtrip():
cookie = auth.sign_pending("user@example.com", 42)
out = auth.verify_pending(cookie)
assert out == {"email": "user@example.com", "uid": 42, "ref": None}
def test_pending_cookie_roundtrip_with_ref():
"""Referral code captured at signup (Phase D.1) rides on the
pending cookie so it survives the POST /login → /verify hop."""
cookie = auth.sign_pending("user@example.com", 42, ref="ABCD1234")
out = auth.verify_pending(cookie)
assert out == {"email": "user@example.com", "uid": 42, "ref": "ABCD1234"}
def test_pending_cookie_rejects_garbage():
assert auth.verify_pending("totally-bogus") is None
assert auth.verify_pending("") is None
def test_pending_cookie_does_not_validate_as_session():
"""Distinct salts: a pending-cookie value must not validate against the
session deserialiser. Otherwise an unverified user could feed their
pending cookie back as cassandra_session and bypass /verify."""
cookie = auth.sign_pending("user@example.com", 42)
assert auth.verify_session(cookie) is None
def test_session_cookie_does_not_validate_as_pending():
cookie = auth.sign_session(7)
assert auth.verify_pending(cookie) is None