2927013a6d
- Updated `.env` and added `.env.test` for environment variables. - Introduced API documentation in `API_DOCUMENTATION.md`. - Added authentication setup guide in `AUTHENTICATION_SETUP.md`. - Implemented user authentication with JWT and email verification. - Created new routes for user management and form submissions. - Added middleware for API key authentication and error handling. - Set up Redis for rate limiting and notifications. - Removed obsolete files and configurations related to the previous Rust implementation.
77 lines
4.4 KiB
Plaintext
77 lines
4.4 KiB
Plaintext
---
|
|
description:
|
|
globs:
|
|
alwaysApply: false
|
|
---
|
|
Objective: Deliver the minimum set of features a user would expect from a basic form backend service.
|
|
|
|
use notes.md to track progress!
|
|
|
|
Task 2.1: User Dashboard & Form Management UI (Replacing current "admin")
|
|
* Mindset Shift: This is no longer your admin panel. It's the user's control center.
|
|
* Subtask 2.1.1: Design User Dashboard Layout:
|
|
* [ ] Wireframe basic layout: List forms, create form, account settings (placeholder).
|
|
* [ ] Decide on frontend tech (EJS is fine for MVP if you make it dynamic with client-side JS, or consider a simple SPA framework if comfortable).
|
|
* Subtask 2.1.2: "My Forms" View:
|
|
* [ ] Fetch and display forms owned by the logged-in user.
|
|
* [ ] Show key info: name, submission count, endpoint URL, created date.
|
|
* [ ] Links to: view submissions, edit settings, delete.
|
|
* Subtask 2.1.3: "Create New Form" Functionality (for logged-in user):
|
|
* [ ] UI and backend logic. Associates form with req.user.id.
|
|
* Subtask 2.1.4: "View Form Submissions" (Scoped & Paginated):
|
|
* [ ] UI and backend for a user to view submissions for their specific form.
|
|
* [ ] Pagination is critical here (as you have).
|
|
* Subtask 2.1.5: Form Settings UI (Basic):
|
|
* [ ] Allow users to update form name.
|
|
* [ ] Placeholder for future settings (thank you URL, notifications).
|
|
* Subtask 2.1.6: Delete Form/Submission (with soft delete/archival consideration):
|
|
* [ ] You have is_archived. Solidify this. Users should be able to archive/unarchive.
|
|
* [ ] True delete should be a confirmed, rare operation.
|
|
|
|
Task 2.2: Per-Form Configuration by User
|
|
* Mindset Shift: Empower users to customize their form behavior.
|
|
* Subtask 2.2.1: Database Schema Updates for forms Table:
|
|
* [ ] Review existing fields (thank_you_url, thank_you_message, ntfy_enabled, allowed_domains). These are good.
|
|
* [ ] Add email_notifications_enabled (boolean).
|
|
* [ ] Add notification_email_address (string, defaults to user's email, but allow override).
|
|
* Subtask 2.2.2: UI for Form Settings Page:
|
|
* [ ] Create a dedicated page/modal for each form's settings.
|
|
* [ ] Allow users to edit: Name, Thank You URL, Thank You Message, Allowed Domains, Email Notification toggle, Notification Email Address.
|
|
* Subtask 2.2.3: Backend to Save and Apply Settings:
|
|
* [ ] API endpoints to update these settings for a specific form (owned by user).
|
|
* [ ] Logic in /submit/:formUuid to use these form-specific settings.
|
|
|
|
Task 2.3: Email Notifications for Submissions (Core Feature)
|
|
* Mindset Shift: Ntfy is cool for you. Users expect email.
|
|
* Subtask 2.3.1: Integrate Transactional Email Service:
|
|
* [ ] Sign up for SendGrid, Mailgun, AWS SES (free tiers available).
|
|
* [ ] Install their SDK. Store API key securely (env vars).
|
|
* Subtask 2.3.2: Email Sending Logic:
|
|
* [ ] Create a service/function sendSubmissionNotification(form, submissionData).
|
|
* [ ] If email_notifications_enabled for the form, send an email to notification_email_address.
|
|
* Subtask 2.3.3: Basic Email Template:
|
|
* [ ] Simple, clear email: "New Submission for [Form Name]", list submitted data.
|
|
* Subtask 2.3.4: Error Handling for Email Sending:
|
|
* [ ] Log errors if email fails to send; don't let it break the submission flow.
|
|
|
|
Task 2.4: Enhanced Spam Protection (Beyond Basic Honeypot)
|
|
* Mindset Shift: Your honeypot is step 1. Real services need more.
|
|
* Subtask 2.4.1: Integrate CAPTCHA (e.g., Google reCAPTCHA):
|
|
* [ ] Sign up for reCAPTCHA (v2 "I'm not a robot" or v3 invisible). Get site/secret keys.
|
|
* [ ] Frontend: Add reCAPTCHA widget/JS to user's HTML form example.
|
|
* [ ] Backend: /submit/:formUuid endpoint must verify reCAPTCHA token with Google.
|
|
* Subtask 2.4.2: User Configuration for Spam Protection:
|
|
* [ ] Allow users to enable/disable reCAPTCHA for their forms (and input their own site key if they want, or use a global one you provide).
|
|
* Subtask 2.4.3: (Future Consideration) Akismet / Content Analysis.
|
|
|
|
Task 2.5: Basic API for Users to Access Their Data
|
|
* Mindset Shift: Power users and integrations need an API.
|
|
* Subtask 2.5.1: API Key Generation & Management:
|
|
* [ ] Allow users to generate/revoke API keys from their dashboard.
|
|
* [ ] Store hashed API keys in DB, associated with user.
|
|
* Subtask 2.5.2: Secure API Endpoints:
|
|
* [ ] Create new API routes (e.g., /api/v1/forms, /api/v1/forms/:uuid/submissions).
|
|
* [ ] Authenticate using API keys (e.g., Bearer token).
|
|
* Subtask 2.5.3: Basic API Documentation:
|
|
|
|
* [ ] Simple Markdown file explaining authentication and available endpoints. |