This is a Hyperclay-compatible HTML editor application that provides secure email-based authentication for editing HTML documents with version control. The app serves both as a public viewer and an authenticated editor interface.

• Storage: Uses Val Town blob storage for persistence
• Versioning: Automatic version history with incremental numbering
• Default Content: Falls back to a Hyperclay starter template when no content exists
• Reset Capability: Admin can reset to default state (dangerous operation)

• Magic Link Auth: Email-based passwordless authentication
• Admin-Only Access: Only the configured admin email can authenticate
• Session Management: 30-day sessions with automatic extension
• Token Security: 15-minute expiring one-time-use tokens

• Edit Mode Cookies: Sets currentResource and isAdminOfCurrentResource cookies for authenticated admins
• Security: Server-side cookie setting with proper security attributes
• View Mode: Cookie clearing for public viewing

Blob Keys:
- `${APP_NAMESPACE}_app` - Current HTML document
- `${APP_NAMESPACE}_app_version_${n}` - Versioned HTML documents
- `${APP_NAMESPACE}_app_version_count` - Version counter
- `${APP_NAMESPACE}_auth_token_${token}` - Magic link tokens (15min TTL)
- `${APP_NAMESPACE}_session_${sessionId}` - User sessions (30day TTL)

• ADMIN_EMAIL - Email address allowed to authenticate (required)
• APP_NAMESPACE - Storage namespace prefix (default: 'default')
• DEBUG - Enable debug logging (default: false)

• Session Cookie: session=${sessionId} - HttpOnly, Secure, 30-day expiry
• Hyperclay Cookies (admin only):
  • currentResource=app - Identifies the resource being edited
  • isAdminOfCurrentResource=true - Enables Hyperclay edit mode

1. GET / - Serve HTML document

   • Check admin status from session cookie
   • Set Hyperclay cookies if admin
   • Return HTML content

2. GET /auth/edit - Show email login form

3. POST /auth/edit - Process email submission

   • Validate admin email
   • Generate magic link token
   • Send email with magic link
   • Show confirmation page

4. GET /auth/verify?token=xxx - Verify magic link

   • Validate and consume token
   • Create session
   • Set session cookie
   • Redirect to main page

5. GET /auth/view - Logout/view mode

   • Clear all cookies
   • Redirect to main page

6. POST /save/app - Save HTML document

   • Verify admin session
   • Validate HTML content
   • Save with versioning
   • Return success response

7. GET /versions - View version history

   • Verify admin session
   • Display all versions with HTML preview

8. POST /reset-dangerous - Reset to default

   • Verify admin session
   • Clear all versions and content
   • Reset to default HTML

1. User enters admin email → Magic link sent
2. User clicks magic link → Token verified & consumed
3. Session created → 30-day cookie set
4. Subsequent requests → Session validated & extended

• Public Access: View HTML document, access auth forms
• Admin Access: Save content, view versions, reset state
• Session Validation: Every admin operation checks session validity

• HttpOnly: Session cookies not accessible to JavaScript
• Secure: Only transmitted over HTTPS
• SameSite=Lax: CSRF protection
• Proper Expiration: Consistent 30-day expiry

• Handler-based routing: Each endpoint has a dedicated handler function
• Modular utilities: Reusable functions for auth, storage, and HTML operations
• Clean separation: Auth logic, business logic, and routing properly separated
• Error boundaries: Consistent error handling throughout the application
• Maintainable code: Easy to understand, test, and extend

• Server-side cookie setting: All cookies set securely on the server with proper attributes
• Enhanced cookie security: All cookies include Secure, SameSite=Lax, and proper expiration
• HttpOnly session cookies: Session cookies cannot be accessed by client-side JavaScript
• Eliminated client-side vulnerabilities: No more JavaScript-based cookie setting

• Focused handlers: Each route has a single-purpose handler function
• Reusable utilities: Common operations extracted into utility functions
• Consistent patterns: Standardized error handling and response formats
• Better debugging: Clear request/response flow and error reporting

• Monolithic Handler: Single 700+ line function handles all routes → Handler-based routing
• Mixed Concerns: Authentication, routing, HTML generation all intermingled → Clean separation
• Repetitive Patterns: Manual response creation throughout → Consistent patterns
• Hard to Test: Tightly coupled logic makes unit testing difficult → Testable handlers

• Route Parsing: Manual URL path checking with if/else chains → Clean routing logic
• Cookie Management: Manual parsing and setting throughout → Utility functions
• Error Handling: Inconsistent error response patterns → Consistent error boundaries
• Content-Type Setting: Repetitive header management → Standardized responses

• Client-side cookie setting: Insecure JavaScript-based cookie management → Server-side security
• Missing security attributes: Cookies lacked proper security flags → Full security attributes
• XSS vulnerability: Session cookies accessible to JavaScript → HttpOnly protection

• Route Separation: Each endpoint is now a focused handler function
• Utility Functions: Common operations extracted and reusable
• Type Safety: Better error handling and response consistency
• Testability: Individual handlers can be easily tested

• Server-side cookies: All cookies set securely on the server
• Proper attributes: Secure, SameSite=Lax, HttpOnly where appropriate
• No client vulnerabilities: Eliminated JavaScript cookie setting
• CSRF protection: SameSite=Lax provides cross-site request forgery protection

• Modular Design: Features developed independently
• Consistent Patterns: Standardized request/response handling
• Easier Debugging: Clear separation of concerns and error boundaries
• Future-Proof: Easy to add new features without touching existing code

Single monolithic handler (700+ lines)
├── Manual route parsing with if/else chains
├── Mixed authentication, routing, and business logic
├── Repetitive response creation patterns
├── Client-side cookie setting (security issue)
└── Hard to test and maintain

Clean handler-based architecture
├── Dedicated handler per route
├── Utility functions for common operations
├── Server-side cookie security
├── Consistent error handling
├── Easy to test and extend
└── Proper separation of concerns