FrameSignal now has two public submission workflows:
- Contact messages on
/contact. - Newsletter signup on the homepage and article detail pages.
Both workflows use Next.js server actions so validation and Supabase writes happen server-side. Neither workflow uses the browser Supabase client, API routes, service role keys, local storage, or client-side trust.
Public users can insert into:
contact_messagesnewsletter_subscribers
Public users cannot read those tables. RLS remains the final database gate, and raw Supabase errors are never shown to public visitors.
The forms use simple manual server-side validation:
- Required fields.
- Basic email format checks.
- Reasonable max lengths.
- A hidden honeypot field.
- Server-side rate limiting when Upstash Redis REST env vars are configured.
If the honeypot is filled, the action returns a generic success path without inserting data. This is lightweight protection only.
Rate limiting uses hashed normalized email keys and does not store raw email, IP addresses, or user-agent strings in Redis. If Upstash env vars are missing, rate limiting is disabled so local development does not break. Production should configure the server-only Upstash env vars before high-traffic use.
This task does not send email notifications, integrate with an email marketing service, add unsubscribe handling, collect IP addresses, add captcha packages, or track analytics.
It also does not add comments, reactions, reader accounts, uploads, storage, admin CRUD changes, API routes, or any update/delete public mutations.
The contact form stores name, email, optional subject, and message. The newsletter form stores email and a safe source label. Privacy and legal pages should be reviewed before real launch so they accurately describe these data flows.
Future tasks can add preview rate-limit verification, email notifications, unsubscribe support, Turnstile/CAPTCHA if needed, and admin review views as separate focused changes.