![]() Server : Apache/2 System : Linux server-15-235-50-60 5.15.0-164-generic #174-Ubuntu SMP Fri Nov 14 20:25:16 UTC 2025 x86_64 User : gositeme ( 1004) PHP Version : 8.2.29 Disable Function : exec,system,passthru,shell_exec,proc_close,proc_open,dl,popen,show_source,posix_kill,posix_mkfifo,posix_getpwuid,posix_setpgid,posix_setsid,posix_setuid,posix_setgid,posix_seteuid,posix_setegid,posix_uname Directory : /home/gositeme/domains/lavocat.quebec/private_html/ |
# Site Down - Fix Instructions
## Problem
Site appears down because JWT session decryption is failing due to NEXTAUTH_SECRET change.
## Quick Fix (Choose One)
### Option 1: Clear Browser Cookies (Fastest)
1. Open your browser
2. Go to site settings
3. Clear all cookies for lavocat.quebec
4. Refresh the page
5. Try logging in again
### Option 2: Call Clear Sessions API
Make a POST request to `/api/clear-all-sessions`:
```bash
curl -X POST https://lavocat.quebec/api/clear-all-sessions
```
Or use a browser console:
```javascript
fetch('/api/clear-all-sessions', { method: 'POST' })
.then(r => r.json())
.then(console.log);
```
### Option 3: Restart Server with Consistent Secret
1. Check current NEXTAUTH_SECRET in `.env`:
```bash
grep NEXTAUTH_SECRET .env
```
2. Update all environment files to use the SAME secret:
- `.env`
- `.env.production`
- `.env.local`
3. Stop the server:
```bash
pkill -f "node.*server"
```
4. Clear session data:
```bash
# Delete session cookies from database
# Or just clear browser cookies
```
5. Restart server:
```bash
npm run dev
```
## Root Cause
The `NEXTAUTH_SECRET` was changed at some point, invalidating all existing session cookies. Users can't authenticate because their old cookies can't be decrypted.
## Prevention
- Never change `NEXTAUTH_SECRET` in production without:
1. Warning users first
2. Implementing a graceful migration
3. Having a plan to clear all sessions
## Current Configuration
- Server: Running on port 3000/3443
- Database: SQLite (dev.db exists)
- NextAuth: Configured with JWT strategy
- Issue: Session decryption failing
## Status Check
After applying fix, test:
1. Can you access `/`
2. Can you log in at `/auth/login`
3. Are API routes working
4. Can you access protected pages