Authentication Deployment Fix

Issue

The production deployment of do.dev was not showing the "Get Started" and "Sign In" buttons in the navbar.

Root Causes

1. Missing NEXT_PUBLIC_PRIMARY_AUTH_URL environment variable
2. SSL certificate issues with clerk.auth.do.dev subdomain
3. Lack of error handling when Clerk fails to load

Solution

1. Environment Variables

The following environment variables need to be set in your production deployment (Vercel):

# Required for Clerk authentication
NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=your-production-clerk-publishable-key
CLERK_SECRET_KEY=your-production-clerk-secret-key
CLERK_WEBHOOK_SECRET=your-production-clerk-webhook-secret

# Primary Auth URL - CRITICAL FOR PRODUCTION
NEXT_PUBLIC_PRIMARY_AUTH_URL=https://auth.do.dev

# Optional Clerk URLs (if using custom domain)
NEXT_PUBLIC_CLERK_DOMAIN=auth.do.dev
NEXT_PUBLIC_CLERK_SIGN_IN_URL=/sign-in
NEXT_PUBLIC_CLERK_SIGN_UP_URL=/sign-up
NEXT_PUBLIC_CLERK_AFTER_SIGN_IN_URL=https://do.dev
NEXT_PUBLIC_CLERK_AFTER_SIGN_UP_URL=https://do.dev

2. Files Updated

• /hooks/useClerkAuth.ts - Added debug logging and fixed error handling
• /middleware.ts - Fixed default localhost port from 3000 to 3005
• /.env.example - Added Clerk environment variables
• /.env.local.example - Added comprehensive Clerk configuration with comments

3. How Authentication Works

1. When Clerk is properly configured:

   • The useAuth hook connects to Clerk and returns the actual authentication state
   • If user is not authenticated, the navbar shows "Get Started" and "Sign In" buttons
   • If user is authenticated, the navbar shows the user menu

2. When Clerk is not configured (missing publishable key):

   • The useAuth hook catches the error and returns isAuthenticated: false
   • The navbar should show "Get Started" and "Sign In" buttons

3. Authentication URLs:

   • Login redirects to: ${NEXT_PUBLIC_PRIMARY_AUTH_URL}/sign-in
   • Signup redirects to: ${NEXT_PUBLIC_PRIMARY_AUTH_URL}/sign-up or /signup
   • Logout redirects to: ${NEXT_PUBLIC_PRIMARY_AUTH_URL}/sign-out

4. Debugging

If authentication buttons are still not showing:

1. Check browser console for the debug log: [useAuth] Clerk auth state:
2. Verify that NEXT_PUBLIC_PRIMARY_AUTH_URL is set correctly in Vercel
3. Ensure Clerk publishable key is valid for the production domain
4. Check that auth.do.dev is properly configured in Clerk dashboard

5. Local Development

For local development, the default configuration uses:

• Auth URL: http://localhost:3005
• This is the port where the dodev app runs locally

Deployment Steps

1. Add all the environment variables listed above to your Vercel project
2. Redeploy the application
3. Clear browser cache and cookies if needed
4. The authentication buttons should now appear correctly

Note

The authentication system is designed to work with a separate auth application running at auth.do.dev. Make sure this is properly deployed and configured before expecting the authentication to work in production.

SSL Certificate Issues

If you see ERR_SSL_VERSION_OR_CIPHER_MISMATCH errors:

1. Ensure clerk.auth.do.dev has a valid SSL certificate
2. Check that the certificate supports modern TLS versions
3. Verify DNS records are properly configured
4. Consider using Clerk's hosted domain initially, then migrate to custom domain

Error Handling

The auth components now include fallback UI that displays when:

• Clerk fails to load due to network/SSL issues
• Environment variables are missing
• Any other authentication errors occur

This ensures users always see login/signup options even when the auth system has issues.

Loading State Fix (July 29, 2025)

Issue

Auth buttons were not showing in production even though Clerk environment variables were present. The buttons were stuck in an infinite loading state.

Root Cause

The DodevAuthStatus component was showing a loading placeholder when isLoading was true. In production, Clerk initialization could fail or take too long, causing isLoading to remain true indefinitely.

Solution

Added a 2-second timeout in DodevAuthStatus component:

• If Clerk hasn't loaded after 2 seconds, show the auth buttons anyway
• This prevents users from being unable to sign in due to Clerk initialization issues
• Console warning is logged when timeout occurs for debugging

Files Updated

• /components/dodev-auth-status.tsx - Added loading timeout with fallback
• /hooks/useClerkAuth.ts - Enhanced logging for all environments
• /components/clerk-client-provider.tsx - Added initialization logging

How It Works

1. Component starts with isLoading = true and shows loading placeholder
2. If Clerk loads successfully, buttons appear normally
3. If Clerk hasn't loaded after 2 seconds, buttons appear anyway
4. Users can always click buttons even if Clerk initialization fails
5. Buttons redirect to appropriate auth pages as fallback

Auth Button Click Fix (July 29, 2025)

Issue

Auth buttons were visible but not working when clicked. Clicking resulted in no action or infinite redirect loops.

Root Cause

1. When Clerk failed to initialize, the fallback redirected to local /login and /signup pages
2. These pages would then call login() or register() in a useEffect, creating an infinite loop
3. The redirect loop prevented users from ever reaching the actual sign-in page

Solution

Updated the fallback auth URLs to redirect directly to https://auth.do.dev instead of local pages:

• Sign in now redirects to: https://auth.do.dev/sign-in
• Sign up now redirects to: https://auth.do.dev/sign-up
• Added comprehensive error handling and logging
• Added click event logging for debugging

Files Updated

• /hooks/useClerkAuth.ts - Changed fallback URLs from local to auth.do.dev
• /components/dodev-auth-status.tsx - Added click event logging

How It Works Now

1. User clicks Sign in/Get Started button
2. If Clerk is available, uses Clerk's redirect methods
3. If Clerk is not available, redirects directly to auth.do.dev
4. Error handling ensures redirect always happens
5. No more infinite redirect loops

Clerk Initialization Fix (July 29, 2025)

Issue

Clerk was stuck in an initialization loop where isLoaded remained false indefinitely in production, preventing authentication from working even though buttons were visible.

Root Cause

Clerk's initialization was failing to complete in production, likely due to:

• Domain configuration mismatch between do.dev and Clerk instance
• CORS or security policies blocking Clerk's initialization requests
• Missing Frontend API configuration in Clerk dashboard

Solution

Added a timeout mechanism in useClerkAuth.ts:

• After 1 second in production (3 seconds in dev), consider Clerk failed to load
• Automatically fallback to auth.do.dev redirect when timeout occurs
• Prevent infinite loading states by forcing effectiveIsLoaded to true

Implementation Details

1. Added clerkLoadTimeout state to track timeout occurrence
2. Created effectiveIsLoaded that overrides Clerk's loading state after timeout
3. Updated login/register/logout to check both loaded state and timeout
4. Added comprehensive logging for debugging initialization issues

How It Works

1. Clerk starts loading with isLoaded = false
2. Timeout timer starts (1s in production, 3s in development)
3. If Clerk loads successfully, normal flow continues
4. If timeout occurs first, clerkLoadTimeout = true
5. Auth methods bypass Clerk and redirect to auth.do.dev
6. Users can always authenticate even if Clerk fails