popertots
7c424b28b8
Loop B restart (money/security/dup-mod adversarial) fixes: - CRITICAL: CreateTerminalPayment rejects payment_type='tip' (mirrors CreateBookingPayment) — a tip-typed admin charge no longer records the FULL amount as a tip and double-collects (all is-paid computations exclude tip rows) - HIGH: tip refunds can no longer re-open booking capacity — refunded_total subqueries filter payment_type <> 'tip' (service.go) and RefundPayment rejects tip rows - MEDIUM: loyalty-stamp farming closed — stamp award once-per-booking via loyalty_stamp_awarded_at column (init-script.sql) + existing same-day guard - MEDIUM: CreateTipPayment/CreateBookingPayment 2FA gates moved AFTER the idempotency completed-dedup (code consumed only on new money paths; terminal path already correct) — lost-response retries return the completed payment instead of 400 - MEDIUM: replayRescueLowerBoundSkew widened to 5m (DB-clock-skew stranded originals now rescued) - MEDIUM-1: verifyFamilyAlive DB amplification reduced via 30s bounded family-alive cache; admin route group rate-limited - MEDIUM-3: admin saved-card charges now write admin_audit_log (handlers.go helper + till); [2FA] log line decoupled from user identity - LOW-1: logout scoped to the presented token's family (no cross-session kill) - LOW-2: refresh-reuse grace widened for same-IP replays - LOW-4: squareEnvironmentMismatch enforced for empty env - LOW-5: uuid.ts hard-fails on Math.random fallback (crypto.randomUUID) - Cash/giftcard tip-enabled overflow mirrors the card-terminal carve 26/26 backend packages; 72/72 frontend tests + build; env-docs 41/41.
69 lines
3.1 KiB
Go
69 lines
3.1 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 (
|
|
"crussell/internal/twofa"
|
|
"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
|
|
|
|
// init registers the dev/test pepper reader into the shared verification core
|
|
// (crussell/internal/twofa): the documented loose-fake fallback — the legacy
|
|
// unsalted SHA-256 digest with a one-time warning when TWO_FACTOR_PEPPER is
|
|
// unset. Production builds fail closed instead (twofa_prod.go).
|
|
func init() {
|
|
twofa.SetPepperProvider(func() 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.
|
|
//
|
|
// MEDIUM-3b: the user id and the plaintext code are written to SEPARATE log
|
|
// lines so a log line cannot trivially pair a code with its owner. The two
|
|
// lines are still correlated by proximity, but a single-line grep or a log
|
|
// redaction rule that masks a "code" pattern no longer discloses the identity
|
|
// in the same record.
|
|
func twoFADeliverCode(userID, label, code string) {
|
|
log.Printf("[2FA] code delivery requested (user=%s, purpose=%s)", userID, label)
|
|
log.Printf("[2FA] code: %s", 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 }
|