mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-08-23 07:32:20 +03:00
0d7c019eec
* feat(radar): shared supporter-key format validator
Extract the "omr_" + 40 hex supporter-key regex out of the
POST /api/radar/settings Zod schema into a pure, client-safe helper
(src/lib/radar/supporterKey.ts) so the format rule lives in exactly one
place and the upcoming activation-screen input can reuse it for a
UX-only pre-check. Server-side Zod validation stays authoritative.
Adds regression coverage: both directions of the format check, a
combined opt-in+supporterKey POST persisting both fields with the key
always masked (never raw) in either the POST or GET response body, and
a flag-off inertia case for the same combined payload shape.
* feat(dashboard): paste-key input on the Radar activation screen
The Radar activation screen had opt-in and the two "get a key" claim
buttons, but nowhere to paste a key someone already has — the last
piece of the supporter flow. Add the field to the activation screen
itself, as the primary path: pasting a key and submitting sends
POST /api/radar/settings with { optIn: true, supporterKey } together,
so pasting a valid key both sets it and unlocks the screen in one step.
Client-side format validation (via the shared isValidSupporterKeyFormat
helper) is a UX nicety only; the server's Zod schema already validates
authoritatively. When a key is already set (hasSupporterKey from
GET /api/radar/settings — e.g. set out of band before this UI existed),
the screen shows the masked form instead of an empty input, with a
"change key" control to paste a new one; the raw key is never
displayed. The existing plain "Activate" button (no key, community
tier) and the two claim/plans buttons are unchanged and still present
below, so all three paths to this screen coexist.
Adds 4 new i18n keys (keySectionTitle, keyInvalidFormatError,
activateWithKeyButton, changeKeyButton) with an English fallback across
all 43 locale files (172 entries) — no __MISSING__ sentinel, no price.
* docs(radar): close the paste-key-input known gap
RADAR.md documented a known gap: the activation screen had no
dedicated key-paste input, only the two claim/plans buttons. That gap
is closed — describe the new input, the combined opt-in+supporterKey
submission, and the masked-key "already activated" state instead.
---------
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
21 lines
899 B
TypeScript
21 lines
899 B
TypeScript
/**
|
|
* supporterKey.ts — pure, client-safe validation for the Radar supporter-key
|
|
* format: "omr_" + 40 lowercase hex chars.
|
|
*
|
|
* Kept free of any server-only import (db, sync) — same pattern as
|
|
* autoSync.ts — so the "use client" Radar activation screen can import it
|
|
* directly for a UX-only pre-check before calling POST /api/radar/settings.
|
|
*
|
|
* This is NOT a security boundary: the server (src/app/api/radar/settings/
|
|
* route.ts) re-validates with the same shape via its Zod schema, which is
|
|
* the authoritative check. Client-side rejection only saves a round trip.
|
|
*/
|
|
|
|
/** "omr_" followed by exactly 40 lowercase hex characters. */
|
|
export const SUPPORTER_KEY_REGEX = /^omr_[0-9a-f]{40}$/;
|
|
|
|
/** Whether `key` matches the supporter-key format. No trimming is performed. */
|
|
export function isValidSupporterKeyFormat(key: string): boolean {
|
|
return SUPPORTER_KEY_REGEX.test(key);
|
|
}
|