Cleanup repository
This commit is contained in:
@@ -1,286 +0,0 @@
|
||||
# Security Scan Report - Wedding Photo Sharing Application
|
||||
**Date**: July 13, 2025
|
||||
**Scanner**: Claude Security Audit with --security --validate flags
|
||||
**Overall Risk Level**: MEDIUM-HIGH
|
||||
|
||||
## Executive Summary
|
||||
|
||||
The wedding photo sharing application demonstrates strong security fundamentals with comprehensive input validation, proper authentication mechanisms, and good file security practices. However, several critical issues require immediate attention, particularly around hardcoded secrets, token storage, and Content Security Policy configuration.
|
||||
|
||||
### Security Score: 6.5/10
|
||||
|
||||
**Strengths**: Excellent input validation, parameterized queries, file security, rate limiting
|
||||
**Critical Issues**: Hardcoded JWT secrets, localStorage token storage, weak CSP, console logging in production
|
||||
|
||||
---
|
||||
|
||||
## 🔴 CRITICAL FINDINGS (Immediate Action Required)
|
||||
|
||||
### 1. Hardcoded JWT Secret in Development
|
||||
- **Location**: Backend `.env` file
|
||||
- **Risk**: Token forgery, authentication bypass
|
||||
- **Impact**: Complete authentication compromise
|
||||
- **Remediation**:
|
||||
```bash
|
||||
# Generate secure secret
|
||||
openssl rand -base64 32
|
||||
# Never commit to repository
|
||||
echo ".env" >> .gitignore
|
||||
```
|
||||
|
||||
### 2. Gallery Tokens in localStorage
|
||||
- **Location**: Frontend `api.ts` and auth contexts
|
||||
- **Risk**: XSS token theft
|
||||
- **Impact**: Gallery access compromise
|
||||
- **Remediation**: Move to httpOnly cookies:
|
||||
```typescript
|
||||
Cookies.set(`gallery_token_${slug}`, token, {
|
||||
httpOnly: true,
|
||||
secure: true,
|
||||
sameSite: 'strict'
|
||||
});
|
||||
```
|
||||
|
||||
### 3. Weak Content Security Policy
|
||||
- **Location**: Frontend `nginx.conf`
|
||||
- **Risk**: XSS, code injection
|
||||
- **Current**: `unsafe-inline` and `unsafe-eval` allowed
|
||||
- **Remediation**: Implement strict CSP (see detailed recommendations below)
|
||||
|
||||
---
|
||||
|
||||
## 🟠 HIGH SEVERITY FINDINGS
|
||||
|
||||
### 1. Console Logging in Production
|
||||
- **Locations**: 61 instances across frontend
|
||||
- **Risk**: Information disclosure
|
||||
- **Impact**: Leaking sensitive data, debugging info
|
||||
- **Remediation**: Implement environment-aware logging
|
||||
|
||||
### 2. Token Revocation Vulnerability
|
||||
- **Location**: Backend `tokenRevocation.js`
|
||||
- **Risk**: Token manipulation
|
||||
- **Impact**: Bypass revocation checks
|
||||
- **Remediation**: Verify token signature before decoding
|
||||
|
||||
### 3. Source Maps in Production
|
||||
- **Location**: Frontend build configuration
|
||||
- **Risk**: Source code exposure
|
||||
- **Impact**: Reveals application structure
|
||||
- **Remediation**: Disable in production builds
|
||||
|
||||
### 4. Missing Security Headers
|
||||
- **Location**: nginx configuration
|
||||
- **Missing**: HSTS, Permissions-Policy
|
||||
- **Impact**: Various client-side attacks
|
||||
- **Remediation**: Add comprehensive security headers
|
||||
|
||||
---
|
||||
|
||||
## 🟡 MEDIUM SEVERITY FINDINGS
|
||||
|
||||
### 1. Rate Limiting Bypass Potential
|
||||
- **Location**: Backend rate limiter
|
||||
- **Risk**: DoS attacks
|
||||
- **Current**: JWT validation in rate limiter
|
||||
- **Remediation**: Use IP-based limiting only
|
||||
|
||||
### 2. Incomplete SQL Injection Protection
|
||||
- **Location**: Complex dashboard queries
|
||||
- **Risk**: Potential injection in edge cases
|
||||
- **Current**: Mostly parameterized
|
||||
- **Remediation**: Use query builder exclusively
|
||||
|
||||
### 3. Session Management
|
||||
- **Issue**: No gallery token invalidation on password change
|
||||
- **Risk**: Persistent access after compromise
|
||||
- **Remediation**: Implement token revocation
|
||||
|
||||
### 4. Path Traversal in Gallery Slugs
|
||||
- **Location**: Frontend gallery routes
|
||||
- **Risk**: Directory traversal attempts
|
||||
- **Remediation**: Validate and sanitize slugs
|
||||
|
||||
---
|
||||
|
||||
## 🟢 LOW SEVERITY FINDINGS
|
||||
|
||||
### 1. Verbose Error Messages
|
||||
- **Location**: Multiple API endpoints
|
||||
- **Risk**: Information disclosure
|
||||
- **Remediation**: Generic client errors, detailed server logs
|
||||
|
||||
### 2. Weak Gallery Passwords
|
||||
- **Current**: zxcvbn score 2/4 allowed
|
||||
- **Risk**: Brute force attacks
|
||||
- **Remediation**: Increase to score 3/4
|
||||
|
||||
### 3. Missing File Size Validation
|
||||
- **Location**: Frontend upload components
|
||||
- **Risk**: DoS via large uploads
|
||||
- **Remediation**: Add client-side size checks
|
||||
|
||||
---
|
||||
|
||||
## ✅ SECURITY STRENGTHS
|
||||
|
||||
### Authentication & Authorization
|
||||
- JWT with proper expiration (24h/7d)
|
||||
- Token type validation
|
||||
- IP tracking and validation
|
||||
- Password change detection
|
||||
- Token revocation system
|
||||
- Bcrypt with 12 rounds
|
||||
- zxcvbn password strength checking
|
||||
|
||||
### Input Validation & SQL Security
|
||||
- express-validator on all endpoints
|
||||
- Parameterized queries via Knex
|
||||
- SQL injection protection utilities
|
||||
- Path traversal prevention
|
||||
- Comprehensive input sanitization
|
||||
|
||||
### File Security
|
||||
- Magic number verification
|
||||
- MIME type validation
|
||||
- Safe filename generation
|
||||
- Directory traversal protection
|
||||
- File extension whitelist
|
||||
|
||||
### Rate Limiting & DoS Protection
|
||||
- General: 100 req/15min
|
||||
- Auth endpoints: 5 req/15min
|
||||
- Account lockout after failed attempts
|
||||
- Suspicious activity detection
|
||||
|
||||
### Frontend Security
|
||||
- React's built-in XSS protection
|
||||
- DOMPurify for HTML content
|
||||
- No eval() or innerHTML usage
|
||||
- Proper error boundaries
|
||||
- ReCAPTCHA integration
|
||||
|
||||
---
|
||||
|
||||
## 📊 DEPENDENCY ANALYSIS
|
||||
|
||||
### Current Status
|
||||
- **Backend**: 0 vulnerabilities (691 packages)
|
||||
- **Frontend**: 0 vulnerabilities (434 packages)
|
||||
|
||||
### Recommended Updates
|
||||
1. **bcrypt** 5.1.1 → 6.0.0 (performance, compatibility)
|
||||
2. **helmet** 7.2.0 → 8.1.0 (new security features)
|
||||
3. **@tiptap** 2.x → 3.x (security improvements)
|
||||
|
||||
### Supply Chain Assessment
|
||||
- All major dependencies from trusted sources
|
||||
- No typosquatting detected
|
||||
- Regular maintenance observed
|
||||
- MIT/ISC/Apache licenses only
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ REMEDIATION PLAN
|
||||
|
||||
### Phase 1: Critical (Within 24 hours)
|
||||
1. Replace hardcoded JWT secret with secure random value
|
||||
2. Move gallery tokens from localStorage to httpOnly cookies
|
||||
3. Implement strict CSP without unsafe-eval
|
||||
4. Remove or wrap console.log statements
|
||||
|
||||
### Phase 2: High Priority (Within 1 week)
|
||||
1. Disable source maps in production
|
||||
2. Add missing security headers (HSTS, Permissions-Policy)
|
||||
3. Fix token revocation vulnerability
|
||||
4. Update critical dependencies (bcrypt, helmet)
|
||||
|
||||
### Phase 3: Medium Priority (Within 1 month)
|
||||
1. Implement comprehensive logging strategy
|
||||
2. Add gallery slug validation
|
||||
3. Enhance rate limiting logic
|
||||
4. Implement session invalidation on password change
|
||||
|
||||
### Phase 4: Ongoing
|
||||
1. Weekly dependency scanning
|
||||
2. Implement security testing in CI/CD
|
||||
3. Regular penetration testing
|
||||
4. Security awareness training
|
||||
|
||||
---
|
||||
|
||||
## 🔒 RECOMMENDED CSP CONFIGURATION
|
||||
|
||||
```nginx
|
||||
add_header Content-Security-Policy "
|
||||
default-src 'self';
|
||||
script-src 'self' 'nonce-{RANDOM}' https://www.google.com/recaptcha/ https://www.gstatic.com/recaptcha/;
|
||||
style-src 'self' 'unsafe-inline';
|
||||
img-src 'self' data: blob: https:;
|
||||
font-src 'self';
|
||||
connect-src 'self' https://analytics.domain.com;
|
||||
frame-src https://www.google.com/recaptcha/;
|
||||
object-src 'none';
|
||||
base-uri 'self';
|
||||
form-action 'self';
|
||||
frame-ancestors 'none';
|
||||
upgrade-insecure-requests;
|
||||
" always;
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🚀 SECURITY IMPROVEMENTS ROADMAP
|
||||
|
||||
### Immediate Implementation
|
||||
```bash
|
||||
# 1. Generate secure secrets
|
||||
openssl rand -base64 32 > jwt-secret.txt
|
||||
|
||||
# 2. Update dependencies
|
||||
cd backend && npm install bcrypt@^6.0.0 helmet@^8.1.0
|
||||
cd ../frontend && npm update
|
||||
|
||||
# 3. Add security scanning
|
||||
npm install -D npm-audit-resolver
|
||||
```
|
||||
|
||||
### CI/CD Integration
|
||||
```yaml
|
||||
# Add to CI pipeline
|
||||
- name: Security Scan
|
||||
run: |
|
||||
npm audit --audit-level=moderate
|
||||
npm run test:security
|
||||
```
|
||||
|
||||
### Monitoring & Alerting
|
||||
1. Implement fail2ban for repeated auth failures
|
||||
2. Set up log analysis for suspicious patterns
|
||||
3. Configure alerts for security events
|
||||
4. Regular vulnerability scanning
|
||||
|
||||
---
|
||||
|
||||
## 📋 COMPLIANCE CHECKLIST
|
||||
|
||||
- [ ] OWASP Top 10 addressed
|
||||
- [ ] GDPR compliance (data minimization, right to erasure)
|
||||
- [ ] Security headers implemented
|
||||
- [ ] Dependency scanning automated
|
||||
- [ ] Incident response plan documented
|
||||
- [ ] Security documentation maintained
|
||||
- [ ] Regular security reviews scheduled
|
||||
|
||||
---
|
||||
|
||||
## 🎯 CONCLUSION
|
||||
|
||||
The wedding photo sharing application has a solid security foundation with excellent input validation and authentication mechanisms. However, operational security practices need immediate attention. The critical issues around secret management and token storage must be addressed before production deployment.
|
||||
|
||||
Implementing the recommended fixes will raise the security score from 6.5/10 to approximately 8.5/10, providing a robust and secure platform for wedding photo sharing.
|
||||
|
||||
---
|
||||
|
||||
*Generated by Claude Security Scanner v1.0*
|
||||
*Next scan recommended: After Phase 1 remediation completion*
|
||||
@@ -47,6 +47,12 @@ jobs:
|
||||
rm -rf frontend/.claudedocs/ || true
|
||||
rm -rf test-maintenance.sh || true
|
||||
rm -rf storage/ || true
|
||||
rm -rf clean-git-history.sh || true
|
||||
rm -rf frontend/.swarm/ || true
|
||||
rm -rf backend/.hive-mind/ || true
|
||||
rm -rf data/ || true
|
||||
rm -rf certbot/ || true
|
||||
|
||||
|
||||
echo "Sensitive files removal completed"
|
||||
|
||||
|
||||
@@ -1,152 +0,0 @@
|
||||
# Backup Version Tracking Implementation
|
||||
|
||||
## Overview
|
||||
Version tracking has been added to the backup system to ensure safe restoration by tracking application versions, Node.js versions, and database schema versions at the time of backup.
|
||||
|
||||
## Implementation Details
|
||||
|
||||
### 1. Database Schema Changes (Migration 034)
|
||||
|
||||
Added version tracking columns to backup tables:
|
||||
|
||||
#### `database_backup_runs` table:
|
||||
- `app_version` - Application version from package.json
|
||||
- `node_version` - Node.js runtime version
|
||||
- `db_schema_version` - Latest migration name
|
||||
- `environment_info` - JSON with additional environment details
|
||||
|
||||
#### `backup_runs` table:
|
||||
- `app_version` - Application version
|
||||
- `node_version` - Node.js version
|
||||
- `db_schema_version` - Database schema version
|
||||
- `manifest_info` - Summary of manifest information
|
||||
|
||||
#### New `restore_history` table:
|
||||
Tracks all restore attempts with comprehensive version information:
|
||||
- Backup versions vs current versions
|
||||
- Compatibility check results
|
||||
- Warnings and errors
|
||||
- Restore outcome
|
||||
|
||||
### 2. Version Information Captured
|
||||
|
||||
During each backup, the system now records:
|
||||
- **Application Version**: From `package.json` (e.g., "1.0.77")
|
||||
- **Node.js Version**: Runtime version (e.g., "v18.17.0")
|
||||
- **Database Schema**: Latest migration file (e.g., "034_add_version_to_backups.js")
|
||||
- **Environment Info**: Platform, architecture, environment mode
|
||||
|
||||
### 3. Backup Services Updated
|
||||
|
||||
#### Database Backup Service (`databaseBackup.js`):
|
||||
- Records version info when creating backups
|
||||
- Includes versions in statistics JSON
|
||||
- New method: `checkVersionCompatibility()` for restore safety
|
||||
- New method: `getCurrentSchemaVersion()` to track migrations
|
||||
|
||||
#### File Backup Service (`backupService.js`):
|
||||
- Records version info in backup_runs table
|
||||
- Integrates with manifest system
|
||||
- Stores manifest summary with version details
|
||||
|
||||
### 4. Existing Manifest System
|
||||
|
||||
The `backupManifest.js` already provides comprehensive version tracking:
|
||||
- Application version and Node.js version
|
||||
- System information (OS, platform, architecture)
|
||||
- Database schema version
|
||||
- Detailed file and database metadata
|
||||
|
||||
### 5. Version Compatibility Checking
|
||||
|
||||
When restoring, the system can now:
|
||||
- Compare backup version vs current version
|
||||
- Detect major/minor version differences
|
||||
- Identify schema mismatches
|
||||
- Provide warnings and recommendations
|
||||
|
||||
### 6. Configuration Settings
|
||||
|
||||
New backup settings for version control:
|
||||
- `backup_require_version_match` - Enforce exact version matching
|
||||
- `backup_allow_minor_version_mismatch` - Allow same major version
|
||||
- `backup_warn_on_version_mismatch` - Show warnings on mismatch
|
||||
- `backup_check_schema_compatibility` - Validate schema versions
|
||||
|
||||
## Usage
|
||||
|
||||
### Creating Backups
|
||||
Backups automatically capture version information - no changes needed to existing backup workflows.
|
||||
|
||||
### Checking Version Before Restore
|
||||
|
||||
1. **For Database Backups**:
|
||||
```javascript
|
||||
const compatibility = await databaseBackupService.checkVersionCompatibility({
|
||||
app_version: '1.0.75',
|
||||
node_version: 'v16.14.0',
|
||||
db_schema_version: '032_add_feedback.js'
|
||||
});
|
||||
|
||||
if (!compatibility.compatible) {
|
||||
console.error('Version mismatch:', compatibility.errors);
|
||||
}
|
||||
```
|
||||
|
||||
2. **For File Backups**:
|
||||
Check the manifest file which contains all version information:
|
||||
```bash
|
||||
cat /backup/path/manifest-backup-20250122-123456.json | jq '.application'
|
||||
```
|
||||
|
||||
### Restore History
|
||||
All restore attempts are logged in the `restore_history` table with:
|
||||
- Version compatibility results
|
||||
- Warnings encountered
|
||||
- Success/failure status
|
||||
- Who performed the restore
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Always Check Compatibility**: Before restoring, verify version compatibility
|
||||
2. **Document Version Changes**: Keep changelog updated with breaking changes
|
||||
3. **Test Restores**: Regularly test restore procedures in staging
|
||||
4. **Monitor Warnings**: Even if compatible, review warnings before proceeding
|
||||
5. **Keep Backups Organized**: Label backups with version info in filename
|
||||
|
||||
## Migration Instructions
|
||||
|
||||
1. Run the new migration:
|
||||
```bash
|
||||
cd backend
|
||||
npm run migrate
|
||||
```
|
||||
|
||||
2. Existing backups will show "unknown" for version fields
|
||||
3. New backups will automatically include version information
|
||||
4. The system remains backward compatible with old backups
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Version Mismatch Errors
|
||||
- Check current app version: `cat backend/package.json | grep version`
|
||||
- Check Node version: `node --version`
|
||||
- Check latest migration: `SELECT name FROM knex_migrations ORDER BY id DESC LIMIT 1`
|
||||
|
||||
### Restore Failures
|
||||
- Review `restore_history` table for detailed error messages
|
||||
- Check version compatibility warnings
|
||||
- Consider using same version environment for critical restores
|
||||
|
||||
## Future Enhancements
|
||||
|
||||
1. **Automated Version Matching**: Docker containers with specific versions
|
||||
2. **Migration Rollback**: Support for downgrading schema safely
|
||||
3. **Version Matrix**: Compatibility matrix for different version combinations
|
||||
4. **Restore Wizard**: UI for guided restore with compatibility checks
|
||||
|
||||
---
|
||||
|
||||
**Implementation Date**: January 2025
|
||||
**Current Version**: 1.0.77
|
||||
**Status**: Production Ready
|
||||
@@ -1,478 +0,0 @@
|
||||
# Comprehensive Backup & Restore Implementation Plan
|
||||
|
||||
## Introduction
|
||||
|
||||
This plan extends the existing backup system to include full database backups, S3/MinIO support, intelligent change detection, and complete restore functionality. The system will create versioned, encrypted backups with manifests for easy restoration while minimizing storage usage through incremental backups and smart scheduling.
|
||||
|
||||
---
|
||||
|
||||
## Phase 1: Enhanced Database Schema & Core Infrastructure
|
||||
|
||||
### Task 1.1: Create Enhanced Database Migration
|
||||
**File:** `backend/migrations/030_enhance_backup_system.js`
|
||||
**Purpose:** Add tables for database backups, restore operations, and backup manifests
|
||||
|
||||
```sql
|
||||
-- backup_manifests table
|
||||
- id (primary key)
|
||||
- backup_run_id (FK to backup_runs)
|
||||
- manifest_version (e.g., "1.0.0")
|
||||
- created_at
|
||||
- database_dump_path
|
||||
- database_checksum
|
||||
- files_manifest (JSON with all file paths/checksums)
|
||||
- metadata (JSON with system info, versions, etc.)
|
||||
|
||||
-- restore_operations table
|
||||
- id (primary key)
|
||||
- started_at
|
||||
- completed_at
|
||||
- status (pending, running, completed, failed)
|
||||
- restore_type (full, partial, database_only, files_only)
|
||||
- source_backup_id (FK to backup_runs)
|
||||
- restored_by (FK to admin_users)
|
||||
- error_message
|
||||
- restore_log (detailed log)
|
||||
|
||||
-- backup_change_tracking table
|
||||
- id (primary key)
|
||||
- table_name
|
||||
- last_change_timestamp
|
||||
- row_count
|
||||
- checksum
|
||||
- last_backed_up
|
||||
```
|
||||
|
||||
### Task 1.2: Add S3 Configuration Settings
|
||||
**File:** Update migration `029_add_backup_service_tables.js`
|
||||
**Add settings:**
|
||||
- `backup_s3_use_ssl` (boolean)
|
||||
- `backup_s3_path_style` (for MinIO compatibility)
|
||||
- `backup_encryption_enabled` (boolean)
|
||||
- `backup_encryption_key` (encrypted storage)
|
||||
- `backup_database_included` (boolean)
|
||||
- `backup_incremental_enabled` (boolean)
|
||||
- `backup_versioning_enabled` (boolean)
|
||||
- `backup_versions_to_keep` (number)
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: S3/MinIO Implementation
|
||||
|
||||
### Task 2.1: Install S3 Dependencies
|
||||
**File:** `backend/package.json`
|
||||
**Command:** `npm install @aws-sdk/client-s3 @aws-sdk/lib-storage mime-types`
|
||||
**Purpose:** AWS SDK v3 for S3-compatible storage
|
||||
|
||||
### Task 2.2: Create S3 Storage Adapter
|
||||
**File:** `backend/src/services/storage/s3Storage.js`
|
||||
**Implementation:**
|
||||
```javascript
|
||||
class S3StorageAdapter {
|
||||
constructor(config)
|
||||
connect() // Test connection
|
||||
uploadFile(localPath, remotePath, metadata)
|
||||
uploadStream(stream, remotePath, metadata)
|
||||
downloadFile(remotePath, localPath)
|
||||
listFiles(prefix)
|
||||
deleteFile(remotePath)
|
||||
getSignedUrl(remotePath, expiresIn)
|
||||
createMultipartUpload(remotePath) // For large files
|
||||
uploadPart(uploadId, partNumber, data)
|
||||
completeMultipartUpload(uploadId, parts)
|
||||
}
|
||||
```
|
||||
|
||||
### Task 2.3: Implement MinIO Compatibility Layer
|
||||
**File:** `backend/src/services/storage/minioCompat.js`
|
||||
**Features:**
|
||||
- Path-style URL handling
|
||||
- Custom endpoint configuration
|
||||
- SSL/TLS options
|
||||
- Bucket creation if not exists
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: Database Backup Integration
|
||||
|
||||
### Task 3.1: Create Database Dump Service
|
||||
**File:** `backend/src/services/databaseBackup.js`
|
||||
**Implementation:**
|
||||
```javascript
|
||||
class DatabaseBackupService {
|
||||
async createBackup(format = 'sql') // sql or json
|
||||
async dumpSQLite(outputPath)
|
||||
async dumpPostgreSQL(outputPath)
|
||||
async compressBackup(inputPath, outputPath)
|
||||
async encryptBackup(inputPath, outputPath, key)
|
||||
async validateBackup(backupPath)
|
||||
async getTableChecksums() // For change detection
|
||||
}
|
||||
```
|
||||
|
||||
### Task 3.2: Implement Change Detection for Database
|
||||
**File:** `backend/src/services/changeDetection.js`
|
||||
**Features:**
|
||||
- Track table modifications using triggers
|
||||
- Calculate table checksums
|
||||
- Compare with last backup state
|
||||
- Intelligent backup decision making
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: Enhanced Backup Service
|
||||
|
||||
### Task 4.1: Refactor Backup Service for S3
|
||||
**File:** `backend/src/services/backupService.js`
|
||||
**Modifications:**
|
||||
- Add `performS3Backup()` implementation
|
||||
- Support multipart uploads for large files
|
||||
- Add progress tracking callbacks
|
||||
- Implement retry logic with exponential backoff
|
||||
|
||||
### Task 4.2: Create Backup Manifest Generator
|
||||
**File:** `backend/src/services/backupManifest.js`
|
||||
**Structure:**
|
||||
```javascript
|
||||
{
|
||||
version: "1.0.0",
|
||||
created_at: "2024-01-20T10:00:00Z",
|
||||
system_info: {
|
||||
app_version: "1.0.74",
|
||||
node_version: "18.x",
|
||||
database_type: "sqlite|postgresql"
|
||||
},
|
||||
database: {
|
||||
dump_file: "database/dump.sql.gz",
|
||||
checksum: "sha256:...",
|
||||
tables: { /* table info */ }
|
||||
},
|
||||
files: {
|
||||
count: 1234,
|
||||
total_size: 5678901234,
|
||||
entries: [
|
||||
{
|
||||
path: "events/active/...",
|
||||
checksum: "sha256:...",
|
||||
size: 12345,
|
||||
modified: "2024-01-20T09:00:00Z"
|
||||
}
|
||||
]
|
||||
},
|
||||
settings: { /* app settings snapshot */ }
|
||||
}
|
||||
```
|
||||
|
||||
### Task 4.3: Implement Incremental Backup Logic
|
||||
**File:** `backend/src/services/incrementalBackup.js`
|
||||
**Features:**
|
||||
- Track changed files since last full backup
|
||||
- Create incremental manifest
|
||||
- Link to parent backup
|
||||
- Merge incremental backups
|
||||
|
||||
---
|
||||
|
||||
## Phase 5: Restore Functionality
|
||||
|
||||
### Task 5.1: Create Restore Service
|
||||
**File:** `backend/src/services/restoreService.js`
|
||||
**Implementation:**
|
||||
```javascript
|
||||
class RestoreService {
|
||||
async validateBackup(backupId)
|
||||
async prepareRestore(backupId, options)
|
||||
async restoreDatabase(manifestPath)
|
||||
async restoreFiles(manifestPath, options)
|
||||
async performFullRestore(backupId)
|
||||
async performPartialRestore(backupId, selections)
|
||||
async rollbackRestore(restoreId)
|
||||
async verifyRestore(restoreId)
|
||||
}
|
||||
```
|
||||
|
||||
### Task 5.2: Implement Safe Restore Process
|
||||
**File:** `backend/src/services/restoreValidation.js`
|
||||
**Safety Features:**
|
||||
- Pre-restore backup creation
|
||||
- Validation checksums
|
||||
- Atomic operations
|
||||
- Rollback capability
|
||||
- Post-restore verification
|
||||
|
||||
### Task 5.3: Create Restore CLI Tool
|
||||
**File:** `backend/scripts/restore-backup.js`
|
||||
**Purpose:** Emergency restore without running application
|
||||
**Features:**
|
||||
- Interactive mode
|
||||
- Dry-run option
|
||||
- Progress display
|
||||
- Validation reports
|
||||
|
||||
---
|
||||
|
||||
## Phase 6: Admin API Extensions
|
||||
|
||||
### Task 6.1: Add Restore Endpoints
|
||||
**File:** `backend/src/routes/adminBackup.js`
|
||||
**New Endpoints:**
|
||||
```javascript
|
||||
POST /api/admin/backup/restore/validate
|
||||
POST /api/admin/backup/restore/start
|
||||
GET /api/admin/backup/restore/:id/status
|
||||
POST /api/admin/backup/restore/:id/cancel
|
||||
GET /api/admin/backup/manifests/:backupId
|
||||
GET /api/admin/backup/download/:backupId
|
||||
```
|
||||
|
||||
### Task 6.2: Add S3 Management Endpoints
|
||||
**File:** `backend/src/routes/adminBackup.js`
|
||||
**New Endpoints:**
|
||||
```javascript
|
||||
GET /api/admin/backup/s3/buckets
|
||||
GET /api/admin/backup/s3/files
|
||||
DELETE /api/admin/backup/s3/cleanup
|
||||
POST /api/admin/backup/s3/test-upload
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 7: Frontend Implementation
|
||||
|
||||
### Task 7.1: Create Backup Management Page
|
||||
**File:** `frontend/src/pages/admin/BackupManagement.jsx`
|
||||
**Components:**
|
||||
- Backup configuration form
|
||||
- Backup history table
|
||||
- Manual backup trigger
|
||||
- Restore interface
|
||||
- Progress indicators
|
||||
|
||||
### Task 7.2: Create Backup Status Dashboard
|
||||
**File:** `frontend/src/components/admin/BackupDashboard.jsx`
|
||||
**Features:**
|
||||
- Real-time backup status
|
||||
- Storage usage charts
|
||||
- Backup success rate
|
||||
- Next scheduled backup
|
||||
- Recent backup/restore operations
|
||||
|
||||
### Task 7.3: Implement Restore Wizard
|
||||
**File:** `frontend/src/components/admin/RestoreWizard.jsx`
|
||||
**Steps:**
|
||||
1. Select backup to restore
|
||||
2. Choose restore type (full/partial)
|
||||
3. Select components (database/files/settings)
|
||||
4. Review and confirm
|
||||
5. Monitor progress
|
||||
6. Verify results
|
||||
|
||||
---
|
||||
|
||||
## Phase 8: Background Job Enhancements
|
||||
|
||||
### Task 8.1: Implement Smart Scheduling
|
||||
**File:** `backend/src/services/smartScheduler.js`
|
||||
**Features:**
|
||||
- Skip backup if no changes detected
|
||||
- Adaptive scheduling based on activity
|
||||
- Priority queuing for critical backups
|
||||
- Resource usage monitoring
|
||||
|
||||
### Task 8.2: Create Backup Monitor Service
|
||||
**File:** `backend/src/services/backupMonitor.js`
|
||||
**Purpose:** Monitor backup health and alert on issues
|
||||
**Features:**
|
||||
- Check last successful backup age
|
||||
- Verify backup integrity periodically
|
||||
- Monitor storage usage
|
||||
- Alert on failures or anomalies
|
||||
|
||||
---
|
||||
|
||||
## Phase 9: Security & Encryption
|
||||
|
||||
### Task 9.1: Implement Backup Encryption
|
||||
**File:** `backend/src/utils/encryption.js`
|
||||
**Features:**
|
||||
- AES-256-GCM encryption
|
||||
- Key derivation from master key
|
||||
- Encrypted manifest headers
|
||||
- Secure key storage
|
||||
|
||||
### Task 9.2: Add Access Control
|
||||
**File:** `backend/src/middleware/backupAuth.js`
|
||||
**Features:**
|
||||
- Separate permissions for backup/restore
|
||||
- Audit logging for all operations
|
||||
- IP whitelist for restore operations
|
||||
- Two-factor authentication for restore
|
||||
|
||||
---
|
||||
|
||||
## Phase 10: Testing & Validation
|
||||
|
||||
### Task 10.1: Create Backup Test Suite
|
||||
**File:** `backend/__tests__/services/backup.test.js`
|
||||
**Tests:**
|
||||
- Unit tests for each backup method
|
||||
- Integration tests with real S3/MinIO
|
||||
- Database backup/restore cycles
|
||||
- Encryption/decryption validation
|
||||
- Manifest generation and parsing
|
||||
|
||||
### Task 10.2: Create Restore Test Suite
|
||||
**File:** `backend/__tests__/services/restore.test.js`
|
||||
**Tests:**
|
||||
- Full restore scenarios
|
||||
- Partial restore validation
|
||||
- Rollback testing
|
||||
- Corruption recovery
|
||||
- Cross-version compatibility
|
||||
|
||||
### Task 10.3: Create E2E Backup/Restore Tests
|
||||
**File:** `backend/__tests__/e2e/backupRestore.test.js`
|
||||
**Scenarios:**
|
||||
- Complete backup/restore cycle
|
||||
- Disaster recovery simulation
|
||||
- Performance benchmarks
|
||||
- Storage optimization validation
|
||||
|
||||
---
|
||||
|
||||
## Phase 11: Documentation & Deployment
|
||||
|
||||
### Task 11.1: Create Backup Administrator Guide
|
||||
**File:** `docs/backup-admin-guide.md`
|
||||
**Contents:**
|
||||
- Configuration guide
|
||||
- Best practices
|
||||
- Troubleshooting
|
||||
- Recovery procedures
|
||||
- Performance tuning
|
||||
|
||||
### Task 11.2: Update Docker Configuration
|
||||
**Files:** `docker-compose.yml`, `Dockerfile`
|
||||
**Changes:**
|
||||
- Add S3/MinIO service for development
|
||||
- Volume mappings for backups
|
||||
- Environment variable templates
|
||||
- Health checks for backup service
|
||||
|
||||
### Task 11.3: Create Backup Playbook
|
||||
**File:** `docs/backup-playbook.md`
|
||||
**Scenarios:**
|
||||
- Daily backup verification
|
||||
- Disaster recovery steps
|
||||
- Migration procedures
|
||||
- Troubleshooting flowchart
|
||||
|
||||
---
|
||||
|
||||
## Implementation Order & Priority
|
||||
|
||||
### Critical Path (Must Have):
|
||||
1. S3 Storage Adapter (Task 2.2)
|
||||
2. Database Backup Service (Task 3.1)
|
||||
3. Enhanced Backup Service (Task 4.1)
|
||||
4. Basic Restore Service (Task 5.1)
|
||||
5. Admin API Extensions (Task 6.1)
|
||||
6. Backup Test Suite (Task 10.1)
|
||||
|
||||
### High Priority (Should Have):
|
||||
1. Backup Manifest Generator (Task 4.2)
|
||||
2. Change Detection (Task 3.2)
|
||||
3. Frontend Backup Page (Task 7.1)
|
||||
4. Encryption Implementation (Task 9.1)
|
||||
5. Restore Wizard (Task 7.3)
|
||||
|
||||
### Nice to Have:
|
||||
1. Incremental Backups (Task 4.3)
|
||||
2. Smart Scheduling (Task 8.1)
|
||||
3. Advanced Monitoring (Task 8.2)
|
||||
4. MinIO Compatibility (Task 2.3)
|
||||
|
||||
---
|
||||
|
||||
## Configuration Examples
|
||||
|
||||
### S3 Configuration:
|
||||
```javascript
|
||||
{
|
||||
backup_destination_type: "s3",
|
||||
backup_s3_endpoint: "https://s3.amazonaws.com",
|
||||
backup_s3_bucket: "wedding-backups",
|
||||
backup_s3_access_key: "AKIA...",
|
||||
backup_s3_secret_key: "secret",
|
||||
backup_s3_region: "us-east-1",
|
||||
backup_s3_use_ssl: true,
|
||||
backup_s3_path_style: false
|
||||
}
|
||||
```
|
||||
|
||||
### MinIO Configuration:
|
||||
```javascript
|
||||
{
|
||||
backup_destination_type: "s3",
|
||||
backup_s3_endpoint: "https://minio.example.com:9000",
|
||||
backup_s3_bucket: "picpeak-backups",
|
||||
backup_s3_access_key: "minioadmin",
|
||||
backup_s3_secret_key: "minioadmin",
|
||||
backup_s3_region: "us-east-1",
|
||||
backup_s3_use_ssl: true,
|
||||
backup_s3_path_style: true // Required for MinIO
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practices Implementation
|
||||
|
||||
1. **Change Detection**: Use database triggers and file checksums to detect changes
|
||||
2. **Compression**: Always compress before encryption for better ratios
|
||||
3. **Chunking**: Split large backups into manageable chunks
|
||||
4. **Versioning**: Keep multiple backup versions with rotation
|
||||
5. **Validation**: Verify every backup immediately after creation
|
||||
6. **Monitoring**: Alert on backup failures within 5 minutes
|
||||
7. **Testing**: Perform monthly restore drills
|
||||
8. **Documentation**: Log every backup/restore operation with details
|
||||
|
||||
---
|
||||
|
||||
## Key Features of This Implementation
|
||||
|
||||
### Intelligent Change Detection
|
||||
- Only backs up when changes are detected
|
||||
- Tracks database modifications via checksums
|
||||
- Monitors file system changes
|
||||
- Reduces unnecessary backup operations
|
||||
|
||||
### Comprehensive Backup Scope
|
||||
- Full database dumps (SQLite/PostgreSQL)
|
||||
- All event photos and thumbnails
|
||||
- Application settings and configuration
|
||||
- Email templates and user data
|
||||
- Complete system state capture
|
||||
|
||||
### Flexible Storage Options
|
||||
- Local directory backup
|
||||
- Remote server via rsync
|
||||
- S3-compatible storage (AWS, MinIO, etc.)
|
||||
- Encrypted storage for security
|
||||
- Compression for space efficiency
|
||||
|
||||
### Robust Restore Capabilities
|
||||
- Full system restore
|
||||
- Partial restore (specific events/data)
|
||||
- Point-in-time recovery
|
||||
- Pre-restore validation
|
||||
- Rollback on failure
|
||||
|
||||
### Enterprise-Grade Features
|
||||
- Backup manifests for verification
|
||||
- Incremental backup support
|
||||
- Version retention policies
|
||||
- Automated cleanup of old backups
|
||||
- Comprehensive audit logging
|
||||
|
||||
This comprehensive plan provides a robust, enterprise-grade backup solution with full disaster recovery capabilities.
|
||||
@@ -1,163 +0,0 @@
|
||||
#!/bin/bash
|
||||
|
||||
# Script to clean git history - removes all commits before July 17, 2025
|
||||
# Safe version: Moves current main to main-old and creates new clean main
|
||||
# WARNING: This will rewrite history!
|
||||
|
||||
set -e
|
||||
|
||||
echo "⚠️ WARNING: This script will rewrite git history!"
|
||||
echo "⚠️ All commits before July 17, 2025 will be removed."
|
||||
echo "⚠️ Current main branch will be preserved as main-old"
|
||||
echo ""
|
||||
read -p "Are you sure you want to continue? (type 'yes' to proceed): " confirmation
|
||||
|
||||
if [ "$confirmation" != "yes" ]; then
|
||||
echo "Operation cancelled."
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Check current state
|
||||
CURRENT_BRANCH=$(git branch --show-current)
|
||||
echo "Current branch: $CURRENT_BRANCH"
|
||||
|
||||
# Check if we're in the middle of a cherry-pick or rebase
|
||||
if [ -d ".git/CHERRY_PICK_HEAD" ] || [ -d ".git/rebase-merge" ] || [ -d ".git/rebase-apply" ]; then
|
||||
echo "ERROR: You're in the middle of a cherry-pick or rebase. Please resolve or abort it first."
|
||||
echo "To abort cherry-pick: git cherry-pick --abort"
|
||||
echo "To abort rebase: git rebase --abort"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Clean any previous attempts
|
||||
echo "Cleaning up any previous attempts..."
|
||||
git cherry-pick --abort 2>/dev/null || true
|
||||
git rebase --abort 2>/dev/null || true
|
||||
|
||||
# Check if main-old already exists
|
||||
if git show-ref --verify --quiet refs/heads/main-old; then
|
||||
echo ""
|
||||
echo "⚠️ Branch 'main-old' already exists!"
|
||||
echo "Options:"
|
||||
echo "1. Delete it and continue (previous backup will be lost)"
|
||||
echo "2. Rename it with timestamp and continue"
|
||||
echo "3. Cancel operation"
|
||||
read -p "Choose option (1/2/3): " option
|
||||
|
||||
case $option in
|
||||
1)
|
||||
echo "Deleting existing main-old branch..."
|
||||
git branch -D main-old
|
||||
;;
|
||||
2)
|
||||
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
|
||||
NEW_NAME="main-old-${TIMESTAMP}"
|
||||
echo "Renaming existing main-old to ${NEW_NAME}..."
|
||||
git branch -m main-old "${NEW_NAME}"
|
||||
;;
|
||||
3)
|
||||
echo "Operation cancelled."
|
||||
exit 1
|
||||
;;
|
||||
*)
|
||||
echo "Invalid option. Operation cancelled."
|
||||
exit 1
|
||||
;;
|
||||
esac
|
||||
fi
|
||||
|
||||
# Make sure we're on main branch
|
||||
if [ "$CURRENT_BRANCH" != "main" ]; then
|
||||
echo "Switching to main branch..."
|
||||
git checkout main
|
||||
fi
|
||||
|
||||
# Move current main to main-old
|
||||
echo "Moving current main branch to main-old..."
|
||||
git branch -m main main-old
|
||||
|
||||
# Find the first commit on or after July 17, 2025
|
||||
echo "Finding first commit after July 17, 2025..."
|
||||
FIRST_COMMIT=$(git log --since="2025-07-17" --reverse --format="%H" | head -1)
|
||||
|
||||
if [ -z "$FIRST_COMMIT" ]; then
|
||||
echo "ERROR: No commits found after July 17, 2025"
|
||||
# Restore main branch
|
||||
git branch -m main-old main
|
||||
exit 1
|
||||
fi
|
||||
|
||||
echo "First commit to keep: $FIRST_COMMIT"
|
||||
echo "Commit details: $(git log --oneline -1 $FIRST_COMMIT)"
|
||||
|
||||
# Count total commits to process
|
||||
TOTAL_COMMITS=$(git log --since="2025-07-17" --oneline | wc -l)
|
||||
echo "Total commits to preserve: $TOTAL_COMMITS"
|
||||
|
||||
# Create new orphan branch for clean main
|
||||
echo "Creating new clean main branch..."
|
||||
git checkout --orphan main
|
||||
|
||||
# Clean the working directory
|
||||
git rm -rf . || true
|
||||
|
||||
# Get the tree from the first commit
|
||||
git checkout $FIRST_COMMIT -- .
|
||||
|
||||
# Create new initial commit with same content
|
||||
ORIGINAL_MESSAGE=$(git log --format="%B" -1 $FIRST_COMMIT)
|
||||
ORIGINAL_AUTHOR=$(git log --format="%an <%ae>" -1 $FIRST_COMMIT)
|
||||
ORIGINAL_DATE=$(git log --format="%ad" -1 $FIRST_COMMIT)
|
||||
|
||||
GIT_AUTHOR_NAME=$(echo "$ORIGINAL_AUTHOR" | cut -d'<' -f1 | xargs)
|
||||
GIT_AUTHOR_EMAIL=$(echo "$ORIGINAL_AUTHOR" | cut -d'<' -f2 | cut -d'>' -f1)
|
||||
GIT_AUTHOR_DATE="$ORIGINAL_DATE"
|
||||
export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE
|
||||
|
||||
git add -A
|
||||
git commit -m "Initial commit - Project start (July 17, 2025)
|
||||
|
||||
Original: $ORIGINAL_MESSAGE"
|
||||
|
||||
# Now rebase the rest of the history onto the new main
|
||||
echo "Rebasing remaining commits..."
|
||||
echo "This will linearize the history (merge commits will be flattened)..."
|
||||
|
||||
# Use rebase to apply all commits
|
||||
git rebase --onto main $FIRST_COMMIT main-old || {
|
||||
echo ""
|
||||
echo "⚠️ Rebase encountered conflicts!"
|
||||
echo ""
|
||||
echo "To resolve:"
|
||||
echo "1. Fix the conflicts in the listed files"
|
||||
echo "2. Stage the resolved files: git add <files>"
|
||||
echo "3. Continue rebase: git rebase --continue"
|
||||
echo "4. If you want to abort and restore: git rebase --abort && git branch -D main && git branch -m main-old main"
|
||||
echo ""
|
||||
echo "After successful rebase, your main branch will have the clean history."
|
||||
echo "The old history is preserved in main-old branch."
|
||||
exit 1
|
||||
}
|
||||
|
||||
# If we get here, rebase was successful
|
||||
echo ""
|
||||
echo "✅ New clean history created successfully!"
|
||||
echo "Total commits in new history: $(git rev-list --count HEAD)"
|
||||
echo ""
|
||||
echo "Branch status:"
|
||||
echo " - main: Clean history starting from July 17, 2025"
|
||||
echo " - main-old: Original history with all commits"
|
||||
echo ""
|
||||
echo "To push the new history to remote, run:"
|
||||
echo " git push origin main --force"
|
||||
echo ""
|
||||
echo "To also push the old history backup:"
|
||||
echo " git push origin main-old"
|
||||
echo ""
|
||||
echo "⚠️ WARNING: Force pushing will overwrite the remote repository!"
|
||||
echo "⚠️ Make sure all team members are aware before pushing!"
|
||||
echo ""
|
||||
echo "If you need to restore the original history:"
|
||||
echo " git checkout main-old"
|
||||
echo " git branch -D main"
|
||||
echo " git branch -m main"
|
||||
@@ -1,123 +0,0 @@
|
||||
#!/bin/bash
|
||||
|
||||
# Script to clean git history - removes all commits before July 17, 2025
|
||||
# Version 2: Handles merge commits properly
|
||||
# WARNING: This is destructive and will rewrite history!
|
||||
|
||||
set -e
|
||||
|
||||
echo "⚠️ WARNING: This script will permanently rewrite git history!"
|
||||
echo "⚠️ All commits before July 17, 2025 will be removed."
|
||||
echo "⚠️ This action cannot be undone!"
|
||||
echo ""
|
||||
read -p "Are you sure you want to continue? (type 'yes' to proceed): " confirmation
|
||||
|
||||
if [ "$confirmation" != "yes" ]; then
|
||||
echo "Operation cancelled."
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Check current state
|
||||
CURRENT_BRANCH=$(git branch --show-current)
|
||||
echo "Current branch: $CURRENT_BRANCH"
|
||||
|
||||
# Check if we're in the middle of a cherry-pick
|
||||
if [ -d ".git/CHERRY_PICK_HEAD" ]; then
|
||||
echo "ERROR: You're in the middle of a cherry-pick. Please resolve or abort it first."
|
||||
echo "To abort: git cherry-pick --abort"
|
||||
echo "To continue: git cherry-pick --continue"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Clean any previous attempts
|
||||
echo "Cleaning up any previous attempts..."
|
||||
git cherry-pick --abort 2>/dev/null || true
|
||||
git checkout main 2>/dev/null || true
|
||||
git branch -D new-main 2>/dev/null || true
|
||||
|
||||
# Create backup branch
|
||||
echo "Creating backup branch..."
|
||||
BACKUP_BRANCH="backup-before-cleanup-$(date +%Y%m%d-%H%M%S)"
|
||||
git checkout -b "$BACKUP_BRANCH"
|
||||
git checkout main
|
||||
|
||||
# Find the first commit on or after July 17, 2025
|
||||
echo "Finding first commit after July 17, 2025..."
|
||||
FIRST_COMMIT=$(git log --since="2025-07-17" --reverse --format="%H" | head -1)
|
||||
|
||||
if [ -z "$FIRST_COMMIT" ]; then
|
||||
echo "ERROR: No commits found after July 17, 2025"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
echo "First commit to keep: $FIRST_COMMIT"
|
||||
echo "Commit details: $(git log --oneline -1 $FIRST_COMMIT)"
|
||||
|
||||
# Count total commits to process
|
||||
TOTAL_COMMITS=$(git log --since="2025-07-17" --oneline | wc -l)
|
||||
echo "Total commits to preserve: $TOTAL_COMMITS"
|
||||
|
||||
# Create new orphan branch
|
||||
echo "Creating new clean history..."
|
||||
git checkout --orphan new-main
|
||||
|
||||
# Clean the working directory
|
||||
git rm -rf . || true
|
||||
|
||||
# Get the tree from the first commit
|
||||
git checkout $FIRST_COMMIT -- .
|
||||
|
||||
# Create new initial commit with same content
|
||||
ORIGINAL_MESSAGE=$(git log --format="%B" -1 $FIRST_COMMIT)
|
||||
ORIGINAL_AUTHOR=$(git log --format="%an <%ae>" -1 $FIRST_COMMIT)
|
||||
ORIGINAL_DATE=$(git log --format="%ad" -1 $FIRST_COMMIT)
|
||||
|
||||
GIT_AUTHOR_NAME=$(echo "$ORIGINAL_AUTHOR" | cut -d'<' -f1 | xargs)
|
||||
GIT_AUTHOR_EMAIL=$(echo "$ORIGINAL_AUTHOR" | cut -d'<' -f2 | cut -d'>' -f1)
|
||||
GIT_AUTHOR_DATE="$ORIGINAL_DATE"
|
||||
export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE
|
||||
|
||||
git add -A
|
||||
git commit -m "Initial commit - Project start (July 17, 2025)
|
||||
|
||||
Original: $ORIGINAL_MESSAGE"
|
||||
|
||||
# Now we'll use git rebase instead of cherry-pick to handle merges better
|
||||
echo "Rebasing remaining commits..."
|
||||
echo "This will linearize the history (merge commits will be flattened)..."
|
||||
|
||||
# Get the commit range
|
||||
LAST_COMMIT=$(git rev-parse main)
|
||||
|
||||
# Use rebase to apply all commits
|
||||
git rebase --onto new-main $FIRST_COMMIT main || {
|
||||
echo ""
|
||||
echo "⚠️ Rebase encountered conflicts!"
|
||||
echo ""
|
||||
echo "To resolve:"
|
||||
echo "1. Fix the conflicts in the listed files"
|
||||
echo "2. Stage the resolved files: git add <files>"
|
||||
echo "3. Continue rebase: git rebase --continue"
|
||||
echo "4. If you want to abort: git rebase --abort"
|
||||
echo ""
|
||||
echo "After successful rebase, run:"
|
||||
echo " git branch -D main"
|
||||
echo " git branch -m main"
|
||||
echo " git push origin main --force"
|
||||
exit 1
|
||||
}
|
||||
|
||||
# If we get here, rebase was successful
|
||||
echo ""
|
||||
echo "✅ New history created successfully!"
|
||||
echo "Total commits in new history: $(git rev-list --count HEAD)"
|
||||
echo ""
|
||||
echo "Your backup branch is: $BACKUP_BRANCH"
|
||||
echo ""
|
||||
echo "To finalize the cleanup, run these commands:"
|
||||
echo " git branch -D main"
|
||||
echo " git branch -m main"
|
||||
echo " git push origin main --force"
|
||||
echo ""
|
||||
echo "⚠️ WARNING: Force pushing will overwrite the remote repository!"
|
||||
echo "⚠️ Make sure you have a backup and all team members are aware!"
|
||||
@@ -1,91 +0,0 @@
|
||||
#!/bin/bash
|
||||
|
||||
# Script to clean git history - removes all commits before July 17, 2025
|
||||
# WARNING: This is destructive and will rewrite history!
|
||||
|
||||
set -e
|
||||
|
||||
echo "⚠️ WARNING: This script will permanently rewrite git history!"
|
||||
echo "⚠️ All commits before July 17, 2025 will be removed."
|
||||
echo "⚠️ This action cannot be undone!"
|
||||
echo ""
|
||||
read -p "Are you sure you want to continue? (type 'yes' to proceed): " confirmation
|
||||
|
||||
if [ "$confirmation" != "yes" ]; then
|
||||
echo "Operation cancelled."
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Create backup branch
|
||||
echo "Creating backup branch..."
|
||||
git checkout -b backup-before-cleanup-$(date +%Y%m%d-%H%M%S)
|
||||
git checkout main
|
||||
|
||||
# Find the first commit on or after July 17, 2025
|
||||
echo "Finding first commit after July 17, 2025..."
|
||||
FIRST_COMMIT=$(git log --since="2025-07-17" --reverse --format="%H" | head -1)
|
||||
|
||||
if [ -z "$FIRST_COMMIT" ]; then
|
||||
echo "ERROR: No commits found after July 17, 2025"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
echo "First commit to keep: $FIRST_COMMIT"
|
||||
echo "Commit details: $(git log --oneline -1 $FIRST_COMMIT)"
|
||||
|
||||
# Get all commits we want to keep
|
||||
COMMITS_TO_KEEP=$(git log --since="2025-07-17" --reverse --format="%H")
|
||||
COMMIT_COUNT=$(echo "$COMMITS_TO_KEEP" | wc -l)
|
||||
echo "Total commits to preserve: $COMMIT_COUNT"
|
||||
|
||||
# Create new orphan branch
|
||||
echo "Creating new clean history..."
|
||||
git checkout --orphan new-main
|
||||
|
||||
# Clean the working directory
|
||||
git rm -rf . || true
|
||||
|
||||
# Get the tree from the first commit
|
||||
git checkout $FIRST_COMMIT -- .
|
||||
|
||||
# Create new initial commit with same content but new message
|
||||
ORIGINAL_MESSAGE=$(git log --format="%B" -1 $FIRST_COMMIT)
|
||||
ORIGINAL_AUTHOR=$(git log --format="%an <%ae>" -1 $FIRST_COMMIT)
|
||||
ORIGINAL_DATE=$(git log --format="%ad" -1 $FIRST_COMMIT)
|
||||
|
||||
GIT_AUTHOR_NAME=$(echo "$ORIGINAL_AUTHOR" | cut -d'<' -f1 | xargs)
|
||||
GIT_AUTHOR_EMAIL=$(echo "$ORIGINAL_AUTHOR" | cut -d'<' -f2 | cut -d'>' -f1)
|
||||
GIT_AUTHOR_DATE="$ORIGINAL_DATE"
|
||||
export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE
|
||||
|
||||
git add -A
|
||||
git commit -m "Initial commit - Project start (July 17, 2025)
|
||||
|
||||
Original: $ORIGINAL_MESSAGE"
|
||||
|
||||
# Cherry-pick remaining commits
|
||||
echo "Applying remaining commits..."
|
||||
REMAINING_COMMITS=$(git log --since="2025-07-17" --reverse --format="%H" $FIRST_COMMIT..main)
|
||||
|
||||
if [ -n "$REMAINING_COMMITS" ]; then
|
||||
for commit in $REMAINING_COMMITS; do
|
||||
echo "Applying: $(git log --oneline -1 $commit)"
|
||||
git cherry-pick $commit || {
|
||||
echo "ERROR: Failed to cherry-pick $commit"
|
||||
echo "You may need to resolve conflicts and continue manually"
|
||||
exit 1
|
||||
}
|
||||
done
|
||||
fi
|
||||
|
||||
echo ""
|
||||
echo "✅ New history created successfully!"
|
||||
echo "Total commits in new history: $(git rev-list --count HEAD)"
|
||||
echo ""
|
||||
echo "To finalize the cleanup, run these commands:"
|
||||
echo " git branch -D main"
|
||||
echo " git branch -m main"
|
||||
echo " git push origin main --force"
|
||||
echo ""
|
||||
echo "⚠️ WARNING: Force pushing will overwrite the remote repository!"
|
||||
echo "⚠️ Make sure you have a backup and all team members are aware!"
|
||||
@@ -1,263 +0,0 @@
|
||||
# PicPeak Security Scan Report
|
||||
|
||||
**Date**: January 12, 2025
|
||||
**Scan Type**: Comprehensive Security Audit
|
||||
**Platform**: PicPeak Photo Sharing Platform
|
||||
**Scanner**: Claude Code Security Scanner
|
||||
|
||||
## Executive Summary
|
||||
|
||||
A comprehensive security scan of the PicPeak photo sharing platform reveals **critical vulnerabilities** that require immediate attention. While the application implements some security best practices, several high-severity issues could lead to data breaches, unauthorized access, and system compromise.
|
||||
|
||||
### Overall Risk Assessment: **HIGH** 🔴
|
||||
|
||||
**Critical Issues Found**: 8
|
||||
**High-Risk Issues**: 7
|
||||
**Medium-Risk Issues**: 6
|
||||
**Low-Risk Issues**: 2
|
||||
|
||||
## Critical Vulnerabilities Requiring Immediate Action
|
||||
|
||||
### 1. Hardcoded Secrets and Credentials 🔴
|
||||
|
||||
#### JWT Secret Fallback
|
||||
- **Location**: `backend/src/routes/protectedImages.js:15,27`
|
||||
- **Severity**: CRITICAL
|
||||
- **Impact**: Complete authentication bypass if environment variable not set
|
||||
```javascript
|
||||
const secret = process.env.JWT_SECRET || 'your-secret-key'; // VULNERABLE
|
||||
```
|
||||
|
||||
#### Default Admin Password
|
||||
- **Location**: `backend/migrations/init.js:14`, `setup-remaining-files.sh:121`
|
||||
- **Severity**: HIGH
|
||||
- **Impact**: Known default credentials allow unauthorized admin access
|
||||
- **Current**: Hardcoded `admin123` password
|
||||
|
||||
### 2. SQL Injection Vulnerabilities 🔴
|
||||
|
||||
#### Direct Template Literal Interpolation
|
||||
- **Location**: `backend/src/routes/adminDashboard.js:214,221,227,252,269`
|
||||
- **Severity**: HIGH
|
||||
- **Impact**: Potential database compromise
|
||||
```javascript
|
||||
.whereRaw(`timestamp >= datetime("now", "-${days} days")`) // VULNERABLE
|
||||
```
|
||||
|
||||
#### LIKE Query Injection
|
||||
- **Locations**:
|
||||
- `backend/src/routes/adminPhotos.js:476`
|
||||
- `backend/src/routes/adminEvents.js:156-158`
|
||||
- **Severity**: MEDIUM
|
||||
- **Impact**: Query manipulation through special characters
|
||||
|
||||
### 3. Authentication & Authorization Flaws 🔴
|
||||
|
||||
#### Missing Token Type Validation
|
||||
- **Location**: Admin middleware
|
||||
- **Severity**: HIGH
|
||||
- **Impact**: Gallery tokens could potentially access admin endpoints
|
||||
|
||||
#### Weak Password Requirements
|
||||
- **Current**: Only 6 characters minimum
|
||||
- **Severity**: MEDIUM
|
||||
- **Impact**: Vulnerable to brute force attacks
|
||||
|
||||
#### Rate Limiting Bypass
|
||||
- **Location**: `backend/server.js:57-73`
|
||||
- **Severity**: HIGH
|
||||
- **Impact**: Invalid JWT tokens bypass rate limiting
|
||||
|
||||
### 4. Cross-Site Scripting (XSS) 🔴
|
||||
|
||||
#### Stored XSS in CMS
|
||||
- **Location**: `frontend/src/pages/public/LegalPage.tsx:106`
|
||||
- **Severity**: CRITICAL
|
||||
- **Impact**: Malicious scripts execute for all visitors
|
||||
```tsx
|
||||
dangerouslySetInnerHTML={{ __html: page.content }} // VULNERABLE
|
||||
```
|
||||
|
||||
### 5. File Upload Vulnerabilities 🟡
|
||||
|
||||
#### Path Traversal Risk
|
||||
- **Location**: `backend/server.js:104-110`
|
||||
- **Severity**: HIGH
|
||||
- **Impact**: Access to files outside intended directories
|
||||
|
||||
#### Insufficient MIME Type Validation
|
||||
- **Multiple locations**
|
||||
- **Severity**: MEDIUM
|
||||
- **Impact**: Malicious file upload bypass
|
||||
|
||||
### 6. Security Headers & Configuration 🟡
|
||||
|
||||
#### Missing Critical Headers
|
||||
- **Missing**: CSP, X-Frame-Options, Strict-Transport-Security
|
||||
- **Severity**: MEDIUM
|
||||
- **Impact**: Reduced defense against various attacks
|
||||
|
||||
#### Permissive CORS Configuration
|
||||
- **Location**: `backend/server.js:30-49`
|
||||
- **Severity**: MEDIUM
|
||||
- **Impact**: Allows multiple origins including localhost
|
||||
|
||||
## Dependency Analysis
|
||||
|
||||
### NPM Audit Results ✅
|
||||
- **Backend**: 0 vulnerabilities found
|
||||
- **Frontend**: 0 vulnerabilities found
|
||||
- **Status**: All dependencies are up to date
|
||||
|
||||
## Detailed Findings by Category
|
||||
|
||||
### Authentication Security
|
||||
|
||||
1. **JWT Implementation Issues**:
|
||||
- No refresh token mechanism
|
||||
- 24-hour token expiration for all types
|
||||
- No token revocation capability
|
||||
- Hardcoded fallback secret
|
||||
|
||||
2. **Session Management**:
|
||||
- In-memory session storage (not scalable)
|
||||
- No Redis implementation despite comments
|
||||
- Incomplete session cleanup
|
||||
|
||||
3. **Password Security**:
|
||||
- Weak requirements (6 chars minimum)
|
||||
- Fixed bcrypt rounds (10)
|
||||
- No password complexity requirements
|
||||
- No breach checking
|
||||
|
||||
### Data Security
|
||||
|
||||
1. **SQL Injection Risks**:
|
||||
- Template literal interpolation in whereRaw()
|
||||
- Unescaped LIKE queries
|
||||
- Missing input validation on some parameters
|
||||
|
||||
2. **XSS Vulnerabilities**:
|
||||
- Stored XSS in CMS content
|
||||
- No Content Security Policy
|
||||
- Missing output encoding in some areas
|
||||
|
||||
3. **Information Disclosure**:
|
||||
- Detailed error messages exposed
|
||||
- Console.error statements with sensitive data
|
||||
- No audit logging for security events
|
||||
|
||||
### Infrastructure Security
|
||||
|
||||
1. **File Upload Issues**:
|
||||
- Path traversal vulnerability
|
||||
- Weak MIME type validation
|
||||
- No virus scanning
|
||||
- Missing content validation
|
||||
|
||||
2. **Network Security**:
|
||||
- Missing security headers
|
||||
- Permissive CORS policy
|
||||
- No HTTPS enforcement
|
||||
- Rate limiting can be bypassed
|
||||
|
||||
## Recommended Fixes
|
||||
|
||||
### Priority 1: Critical (Implement Immediately)
|
||||
|
||||
1. **Remove Hardcoded Secrets**
|
||||
```javascript
|
||||
// Replace fallback with error
|
||||
const secret = process.env.JWT_SECRET;
|
||||
if (!secret) {
|
||||
throw new Error('JWT_SECRET environment variable is required');
|
||||
}
|
||||
```
|
||||
|
||||
2. **Fix SQL Injection**
|
||||
```javascript
|
||||
// Use parameterized queries
|
||||
.whereRaw('timestamp >= datetime("now", ? || " days")', [`-${days}`])
|
||||
```
|
||||
|
||||
3. **Sanitize CMS Content**
|
||||
```javascript
|
||||
import DOMPurify from 'dompurify';
|
||||
dangerouslySetInnerHTML={{ __html: DOMPurify.sanitize(page.content) }}
|
||||
```
|
||||
|
||||
### Priority 2: High (Implement Within 1 Week)
|
||||
|
||||
1. **Add Token Type Validation**
|
||||
```javascript
|
||||
if (decoded.type !== 'admin') {
|
||||
return res.status(401).json({ error: 'Invalid token type' });
|
||||
}
|
||||
```
|
||||
|
||||
2. **Implement Security Headers**
|
||||
```javascript
|
||||
app.use(helmet({
|
||||
contentSecurityPolicy: {
|
||||
directives: {
|
||||
defaultSrc: ["'self'"],
|
||||
scriptSrc: ["'self'", "'unsafe-inline'"],
|
||||
styleSrc: ["'self'", "'unsafe-inline'"],
|
||||
imgSrc: ["'self'", "data:", "https:"],
|
||||
},
|
||||
},
|
||||
}));
|
||||
```
|
||||
|
||||
3. **Fix Rate Limiting Bypass**
|
||||
```javascript
|
||||
// Check token validity before skipping rate limit
|
||||
try {
|
||||
const decoded = jwt.verify(token, process.env.JWT_SECRET);
|
||||
return decoded && decoded.type === 'admin';
|
||||
} catch (err) {
|
||||
return false; // Apply rate limiting on invalid tokens
|
||||
}
|
||||
```
|
||||
|
||||
### Priority 3: Medium (Implement Within 1 Month)
|
||||
|
||||
1. **Enhance Password Security**
|
||||
- Minimum 12 characters
|
||||
- Complexity requirements
|
||||
- Breach checking integration
|
||||
|
||||
2. **Implement File Security**
|
||||
- Content-based validation
|
||||
- Path traversal protection
|
||||
- Virus scanning
|
||||
|
||||
3. **Add Security Monitoring**
|
||||
- Audit logging
|
||||
- Failed login tracking
|
||||
- Anomaly detection
|
||||
|
||||
## Security Checklist
|
||||
|
||||
- [ ] Remove all hardcoded secrets
|
||||
- [ ] Fix SQL injection vulnerabilities
|
||||
- [ ] Add XSS protection (DOMPurify)
|
||||
- [ ] Implement proper token validation
|
||||
- [ ] Add all security headers
|
||||
- [ ] Fix rate limiting bypass
|
||||
- [ ] Enhance password requirements
|
||||
- [ ] Add file upload security
|
||||
- [ ] Implement audit logging
|
||||
- [ ] Set up security monitoring
|
||||
- [ ] Document security procedures
|
||||
- [ ] Conduct penetration testing
|
||||
|
||||
## Conclusion
|
||||
|
||||
The PicPeak platform has significant security vulnerabilities that need immediate attention. The most critical issues are hardcoded secrets, SQL injection risks, and stored XSS vulnerabilities. While the codebase shows some security awareness (bcrypt hashing, JWT usage, input validation), the implementation has serious flaws that could lead to system compromise.
|
||||
|
||||
**Recommended Action**: Address all critical vulnerabilities immediately before deploying to production. Consider a professional security audit after implementing these fixes.
|
||||
|
||||
---
|
||||
*Generated by Claude Code Security Scanner*
|
||||
*Scan completed: 2025-01-12*
|
||||
@@ -1,45 +0,0 @@
|
||||
# Package Upgrade Summary - Production System
|
||||
Date: 2025-07-22
|
||||
|
||||
## ✅ Successfully Upgraded (8 packages)
|
||||
|
||||
### Phase 1 (Low Risk):
|
||||
**Backend:**
|
||||
- i18next: 25.3.1 → 25.3.2
|
||||
- bcrypt: 5.1.1 → 6.0.0
|
||||
- nodemailer: 6.10.1 → 7.0.5
|
||||
|
||||
**Frontend:**
|
||||
- date-fns: 2.30.0 → 4.1.0
|
||||
- lucide-react: 0.292.0 → 0.525.0
|
||||
|
||||
### Phase 2 (Medium Risk - Carefully Tested):
|
||||
**Backend:**
|
||||
- sharp: 0.32.6 → 0.34.3
|
||||
- chokidar: 3.6.0 → 4.0.3
|
||||
|
||||
**Frontend:**
|
||||
- react-toastify: 9.1.3 → 11.0.5
|
||||
|
||||
## 🚫 Deferred Upgrades (High Risk)
|
||||
|
||||
### Critical Bug Found:
|
||||
- **archiver**: MUST stay at 5.3.2 (v7 has append() bug that breaks watermarks)
|
||||
|
||||
### Major Breaking Changes:
|
||||
- express 4 → 5
|
||||
- knex 2 → 3
|
||||
- React 18 → 19
|
||||
- tailwindcss 3 → 4
|
||||
|
||||
## Security Status
|
||||
- **npm audit vulnerabilities: 0** ✅
|
||||
- All upgraded packages tested and working
|
||||
- No known security issues in current packages
|
||||
|
||||
## Backup Locations
|
||||
- Phase 1: `/backups/phase1-upgrade-20250722-103923/`
|
||||
- Phase 2: `/backups/phase2-upgrade-20250722-104940/`
|
||||
|
||||
## Production Ready
|
||||
All upgrades have been tested and are ready for production deployment. Monitor closely for 48 hours after deployment.
|
||||
Reference in New Issue
Block a user