Money-safety: - Deterministic till idempotency fallback (Square-charging only); cash/on_the_house keep unique keys; £250 till gift-card cap; 45-char key validation - Gift-card admin caps £250/tx + £5,000/day; user buy £500/day; BuyGiftCard allowlist unchanged - CancelGiftCard: CCR 2013 14-day right with partial-spend refund of the unspent balance (spend verified via payments.gift_card_id); atomic vs redeem/transfer; refunds stay pending until reversal commits; admin cancel surface (AdminCancelGiftCard) - Sweep: cancelled-booking charges failed+notified instead of silently completed; source-override replay uses live square_source_id; legacy square-less refund sweep; snapshot refresh on pending reuse - Refund lock consolidation; recordTerminalPaymentTx shared recorder; structured Square error codes; terminal checkout CustomerID GDPR / security: - Notes retained as de-identified medical/safety record at erasure (single field treated as health data; rest of record wiped, no re-identification map) + comments updated per UK GDPR/Art 9/Equality Act 2010 - square_request_snapshot PII scrubbed on all erasure paths; delete_guest_user FK unlinks; verification codes + dispute reasons handled; idle/stale-guest erasure deletes Square cards/customers + CardDAV/R2 - Durable square-erasure outbox job (retry-square-erasures); 2FA dev/prod build split, pepper fail-closed, no prod code-in-log; prod 2FA delivery fail-loud without a channel - Webhook unknown-type family split (non-money acked, money retried); untracked dispute notifications; rate-limit CF/X-Real-IP trust gating; nginx CSP nonce + api_limit Frontend: - Dynamic z-index stack (ui/dialog/zindex.ts) claimed in open order via data-state observer; re-claims on every reopen; removes stale !z-* overrides — nested modals (booking→user→booking) always paint newest-on-top (browser-verified 3-level + reopen) - Mobile: iOS zoom fixes, bottom-sheet dialogs, 44px touch targets, inputmode decimal, dvh - Gift-card buy/cancel UI, admin £250 + daily limits, cancellation/privacy/terms policy accuracy S3: - Connect() creates buckets before probing; in-memory fallback only on genuine unreachability; health reports degraded; stale S3_PUBLIC_URL documented (host-specific) Tests/docs: - 2263 test functions; all 22 backend packages green; round8/9/10 regression suites; NextEditWindowTime removes wall-clock flake; docs reconciled (notes retention, gift-card partial-use, modal T15 future work)
59 lines
2.6 KiB
Go
59 lines
2.6 KiB
Go
//go:build dev || test
|
|
|
|
package user
|
|
|
|
// Dev/test builds (the `dev` tag, or any build with the `test` tag) keep the
|
|
// documented loose-fake 2FA delivery: the plaintext code is written to the
|
|
// server log ([2FA] prefix) as the stand-in for the not-yet-wired email/SMS
|
|
// transport (P6), and a missing TWO_FACTOR_PEPPER still falls back to the
|
|
// legacy unsalted SHA-256 digest. Production builds (!dev && !test) instead
|
|
// never log the code and fail closed without the pepper — see twofa_prod.go.
|
|
|
|
import (
|
|
"log"
|
|
"os"
|
|
"sync"
|
|
)
|
|
|
|
// twoFAPepperWarnOnce guards the one-time warning when TWO_FACTOR_PEPPER is
|
|
// unset, so a misconfigured deployment is loudly flagged once rather than on
|
|
// every code operation. Dev/test only: production builds fail closed at
|
|
// issuance instead.
|
|
var twoFAPepperWarnOnce sync.Once
|
|
|
|
// twoFAPepper returns the configured HMAC pepper, or "" when unset, logging the
|
|
// documented one-time warning. Read per call (the rest of the backend reads env
|
|
// vars per call too) so a value provisioned at runtime is picked up; only the
|
|
// warning is gated on sync.Once.
|
|
func twoFAPepper() string {
|
|
pepper := os.Getenv(twoFAPepperEnv)
|
|
if pepper == "" {
|
|
twoFAPepperWarnOnce.Do(func() {
|
|
log.Printf("WARNING: TWO_FACTOR_PEPPER unset — 2FA codes hashed without an HMAC pepper (falling back to unsalted SHA-256); set TWO_FACTOR_PEPPER in production so a leaked digest cannot be brute-forced offline")
|
|
})
|
|
}
|
|
return pepper
|
|
}
|
|
|
|
// twoFAEnsureIssueAllowed always permits code issuance in dev/test builds: the
|
|
// loose-fake delivery (the [2FA] log line) is the documented stand-in until the
|
|
// email/SMS transport is wired (P6). Production builds fail closed here — no
|
|
// TWO_FACTOR_PEPPER, no codes (see twofa_prod.go).
|
|
func twoFAEnsureIssueAllowed() error { return nil }
|
|
|
|
// twoFADeliverCode delivers a fresh verification code to the user. Dev/test:
|
|
// the [2FA] log line is the delivery channel — an operator relays the code to
|
|
// the user out-of-band until email/SMS lands. Production builds log it ONLY
|
|
// when the operator explicitly opts in via TWO_FACTOR_ALLOW_LOG_DELIVERY=true
|
|
// (see twofa_prod.go); otherwise they refuse issuance up front.
|
|
func twoFADeliverCode(userID, label, code string) {
|
|
log.Printf("[2FA] verification code for user %s (%s): %s", userID, label, code)
|
|
}
|
|
|
|
// twoFADeliveryAvailable reports whether a 2FA code delivery channel exists in
|
|
// this build. Dev/test: always true — the [2FA] log line is the delivery
|
|
// channel. Production builds only have a channel when the operator explicitly
|
|
// opted into log delivery or a real email/SMS transport is wired (P6) — see
|
|
// twofa_prod.go.
|
|
func twoFADeliveryAvailable() bool { return true }
|