Fixes issues where toggle became unresponsive and triggered recursive calls:
1. Add flags (updatingOWASPStatus, updatingComodoStatus) to prevent change
event handlers from triggering when status check updates toggle state
2. Guard change event handlers to return early when flags are set
3. IMPORTANT: Still increment counters when returning early to maintain
correct counter state for subsequent user clicks
4. Set flags before updating toggle via prop('checked'), reset after 100ms
5. Use timeout delays (500ms) before status checks after install/uninstall
to allow operations to complete and prevent race conditions
This ensures:
- Toggle responds correctly to user clicks on first click
- Status updates don't trigger unwanted installations
- Counter state is maintained even when skipping automatic updates
- No recursive loops when updating toggle state
Fixes issues where toggle became unresponsive and triggered recursive calls:
1. Add flags (updatingOWASPStatus, updatingComodoStatus) to prevent change
event handlers from triggering when status check updates toggle state
2. Guard change event handlers to return early when flags are set
3. Set flags before updating toggle via prop('checked'), reset after 100ms
4. Use timeout delays (500ms) before status checks after install/uninstall
to allow operations to complete and prevent race conditions
This ensures:
- Toggle responds correctly to user clicks
- Status updates don't trigger unwanted installations
- No recursive loops when updating toggle state
- Clean separation between user actions and status updates
This commit resolves issues where the OWASP CRS toggle in ModSecurity settings
would appear to flip back to OFF even when installation succeeded, and improves
detection of manually installed OWASP CRS rules.
Issues Fixed:
1. Toggle not updating immediately after installation/uninstallation
2. Manual OWASP installations to rules.conf not detected by toggle
3. Silent installation failures without detailed error logging
Changes:
firewall/static/firewall/firewall.js:
- Update toggle state immediately after successful installation (getOWASPAndComodoStatus(true))
- Update toggle state after failed installation to show correct OFF state
- Provides instant visual feedback instead of requiring page refresh
firewall/firewallManager.py (getOWASPAndComodoStatus):
- Expand detection logic to check both httpd_config.conf AND rules.conf
- Detect manual OWASP installations (Include/modsecurity_rules_file with owasp/crs-setup)
- Case-insensitive pattern matching for better compatibility
plogical/modSec.py (setupOWASPRules):
- Add specific error logging for each installation step failure
- Log detailed messages: directory creation, download, extraction, configuration
- Helps diagnose: network issues, missing tools (wget/unzip), permission problems
Impact:
- Toggle correctly reflects OWASP CRS state after enable/disable operations
- Manual installations following external tutorials now detected correctly
- Installation failures are logged with specific error messages for debugging
- Improves UX by eliminating perception that "toggle keeps flipping back"
Fixes: OWASP CRS toggle UI bug
Related: Community thread https://community.cyberpanel.net/t/4-mod-security-rules-packages/133/8
Related: Ticket #GTPDPO7EV
This commit resolves the issue where CyberPanel attempts to configure email/DKIM settings
even when email services were explicitly disabled during custom installation, causing
hostname SSL setup and website creation to fail with "No such file or directory: '/etc/postfix/main.cf'" errors.
Changes:
- Added emailServicesInstalled() utility function to check for /home/cyberpanel/postfix marker
- OnBoardingHostName(): Wrap email operations (issueSSLForMailServer, postfix commands) with checks
- OnBoardingHostName(): Allow hostname setup to complete without email services
- issueSSLForMailServer(): Add early return if email services not installed
- issueSSLForMailServer(): Verify /etc/postfix directory exists before operations
- issueSSLForMailServer(): Check /etc/postfix/main.cf exists before reading
- setupAutoDiscover(): Add early return if email services not installed
- setupAutoDiscover(): Check /etc/postfix/main.cf exists before accessing
- mailUtilities.configureOpenDKIM(): Verify main.cf exists before configuration
Impact:
- Hostname SSL setup now completes successfully without email components
- Website creation works correctly on custom installs without email
- No more file not found errors for /etc/postfix/main.cf
- Graceful degradation: operations skip email setup with log messages
Fixes: Custom installation hostname SSL 404 error
Fixes: Website creation DKIM failure on custom installs
Related: Ticket #RMKRFFGKC
- Verify lscgctl works after running lssetup
- Retry with more slices (-c 10) if first attempt fails
- Add detailed logging to debug setup issues
- Add time.sleep() to give lssetup time to initialize
- Provide clear error messages if setup fails
- Fetch actual resource limits from lscgctl command in loadDomainHome
- Parse JSON output and extract CPU, Memory, I/O, Tasks values
- Display resource limits in dedicated section on website detail page
- Only show limits if they actually exist on the site
- Use modern card design with gradients matching the rest of the UI
- Pass --io parameter to lscgctl with bytes/sec value
- Convert ioLimitMBPS from MB/s to bytes/s for lscgctl
- Update log message to include I/O limit information
- Add note about systemd io controller delegation requirement
- Change all addon purchase links to https://cyberpanel.net/cyberpanel-addons
- Update error messages in package creation and modification
- Update UI links in create and modify package templates
- Improve link text to 'Purchase CyberPanel Addons'
- Add addon access check via platform.cyberpersons.com API
- Validate addon access in package creation and modification
- Prevent enabling enforceDiskLimits without addons
- Reset resource limits to defaults if addons not available
- Hide resource limits UI for non-addon users
- Show informative message directing users to enable addons
- Apply same restrictions to both create and modify package flows
- Complete documentation for using resource limits in CyberPanel
- Prerequisites and system requirements
- Step-by-step setup instructions
- Verification and testing procedures
- Troubleshooting guide
- Package recommendations for different hosting tiers
- FAQ section
- Add test to verify LiteSpeed Containers is actually configured
- Check for 'You must configure LiteSpeed' error in lscgctl output
- Run lssetup with proper flags when configuration is needed
- Fixes issue where lscgctl exists but LiteSpeed Containers not configured
Detect RHEL 8, AlmaLinux 8, Rocky Linux 8, and CloudLinux 8 systems and provide
clear instructions when cgroups v2 needs manual enablement.
These systems have cgroups v2 backported to kernel 4.18 but it's disabled by
default. When detected without cgroups v2 enabled, the system now:
1. Detects RHEL 8 family by checking /etc/redhat-release
2. Verifies if cgroups v2 is mounted (checks 'mount' output for 'cgroup2')
3. If not enabled, logs detailed instructions:
- grubby command to add kernel parameter
- Reboot instruction
- Verification command
- Clear step-by-step guide
Changes:
- _check_rhel8_cgroups_v2(): New method for RHEL 8 family detection
- _ensure_cgroups_enabled(): Calls RHEL 8 check before general checks
- check_cgroup_support(): Returns RHEL 8 status in support dict
- rhel8_family: bool (detected RHEL 8 family)
- rhel8_needs_enablement: bool (cgroups v2 not mounted)
- os_name: str (full OS name from release file)
OS Support Status:
✅ Ubuntu 20.04+ - Native cgroups v2 (kernel 5.4+)
✅ RHEL/Alma/Rocky 9+ - Native cgroups v2 (kernel 5.14+)
⚠️ RHEL/Alma/Rocky/CloudLinux 8 - Needs manual enable (kernel 4.18 backported)
- Add green gradient banner with modern design and animations
- Display text: Full .htaccess support • PHP configuration now works • Zero rule rewrites needed
- Link to https://cyberpanel.net/cyberpanel-htaccess-module
- Include ripple effect on button hover and rotation on close
- Add smart dismissal logic with localStorage persistence
- Show banner once per day with staggered delay for better UX
- Support mobile responsive design with flexible layout
- Position banner properly when multiple notifications are shown
Reduce minimum file size from 1MB to 10KB to allow the module file
(~35KB) to pass validation. The 1MB threshold was too strict and only
appropriate for the main OLS binary. Now displays size in KB or MB
appropriately.
Change download verification to check file existence and size instead of
relying on return code. The wget command succeeds but install_utils.call()
may not return 0. Now verifies downloaded file exists and is at least 1MB.
Integrate custom OLS binaries during installation to enable Apache-style
php_value/php_flag directives in .htaccess files. The installer now:
- Downloads custom OLS binary and module from cyberpanel.net
- Creates backup of existing binaries before replacement
- Installs custom binaries with enhanced .htaccess support
- Configures CyberPanel module in OpenLiteSpeed config
- Gracefully falls back to standard OLS if download fails
- Only installs on x86_64 architecture
Features enabled by custom binaries:
- Apache-style .htaccess support
- php_value and php_flag directives
- Enhanced header control
- Better Apache compatibility
Problem: Bulk fix operations were hitting rate limits (100 backups per scan).
Solution:
- Implemented 10x higher rate limits for API key authenticated requests
- These are trusted requests from the platform for legitimate bulk operations
- Regular file token auth keeps original limits for security
Rate Limit Changes:
- backup-file: 100 → 1000 for API key auth
- get-file: 500 → 5000 for API key auth
- replace-file: 100 → 1000 for API key auth
- rename-file: 50 → 500 for API key auth
- delete-file: 50 → 500 for API key auth
This allows bulk fix operations to process up to 1000 files without hitting rate limits,
while maintaining security for regular scan operations.
Problem: VPS API keys were generated dynamically but never saved to the database,
causing file fix operations to fail with "Invalid token" error.
Root Cause:
- When CyberPanel runs on VPS, it calls platform's /api/vps/generate-api-key/
- The returned API key was used for scan submission but not persisted
- Later file fix operations couldn't validate this API key
Solution:
- Save VPS API key to ai_scanner_settings table whenever obtained
- Modified 4 locations where VPS API key is retrieved:
1. startScan() - Save when initiating a scan
2. getPlatformMonitorUrl() - Save when checking scan status
3. addPaymentMethod() - Save when configuring payment (2 locations)
Implementation:
- Use get_or_create() to ensure scanner settings exist
- Update existing settings if API key is empty or different
- Set is_payment_configured=True for VPS accounts (implicit payment)
- Continue operation even if saving fails (non-blocking)
Result:
- VPS API keys are automatically persisted on first use
- File fixes work without manual database intervention
- All AI Scanner features work seamlessly on VPS instances
Problem: "Failed to backup file before replacement" error when using API key authentication.
Root Cause:
- The externalApp field (which contains the system user for file operations) was sometimes None
- When using API key authentication, the code couldn't determine which user to run commands as
Solution:
- Added fallback logic to ensure we always have a valid user for file operations:
1. First try wp_site.owner.externalApp
2. If not set, try Websites.objects.get(domain).externalApp
3. If still not set, fall back to admin username
- Added detailed error messages and logging throughout backup operations
- Enhanced error reporting to include user context and operation details
- Added validation for backup directory creation with proper error handling
Changes:
- Modified validate_access_token() OPTION 2 and OPTION 3 to ensure external_app is always set
- Enhanced backup and replace operations with better error messages
- Added detailed logging for debugging file operation failures
- Include user context in error messages for easier troubleshooting
This ensures file operations work correctly even when externalApp field is not properly configured.
Problem: File fixes were failing with "Invalid token" even though the platform was sending the correct API key.
Solution:
- Updated validate_access_token() to accept CyberPanel's own API keys for file operations
- Added three validation options:
1. FileAccessToken (temporary tokens for active scans)
2. API key validation with less restrictive admin check
3. Simple validation for platform callbacks (any valid API key + valid scan)
- Added extract_auth_token() helper to support both Bearer and X-API-Key headers
- Created debug endpoints for testing authentication (/api/ai-scanner/test-auth)
- Added test script for validation testing (supports remote servers via env vars)
This fix allows the platform to use CyberPanel's API key to fix files for any scan,
solving the "File access token has expired" issue for older scans.
Usage for remote testing:
CYBERPANEL_SERVER=http://your-server:8001 \
CYBERPANEL_API_KEY=cp_your_key \
CYBERPANEL_SCAN_ID=your-scan-id \
./test_api_key_fix.sh
- Added extract_auth_token() function to handle both Bearer and X-API-Key authentication
- Updated all file operation endpoints to support X-API-Key headers:
- list_files()
- get_file_content()
- scanner_backup_file()
- scanner_get_file()
- scanner_replace_file()
- scanner_rename_file()
- scanner_delete_file()
- Maintains backward compatibility with existing Bearer token authentication
- Added test script to verify both authentication methods work correctly
- Enables permanent API key authentication for file fixes (no more expired token issues)
This change allows the platform to fix files using the permanent CyberPanel API key
instead of temporary file access tokens that expire after ~1 hour.
- Write temp files to /tmp (accessible by all users)
- Website user can read from /tmp for cat command
- No permission issues with cross-directory operations
- Simplifies file operations (no intermediate copy needed)
- Clean up temp file with os.remove() as root
- Fixes: Files becoming empty due to permission issues
- Shell redirection requires shell=True parameter in executioner
- Without shell=True, the > is treated as literal argument
- Fixes: File contents not being replaced
- Change from cp to 'cat temp > target' for replacing file contents
- cat redirection is more reliable for overwriting existing files
- Ensures file contents are actually replaced
- Fixes: Files not being replaced even though cp returns success
- Write to /home/cyberpanel temp first (no user permission issues)
- Copy from /home/cyberpanel to user directory using executioner
- Use cp instead of mv for final file replacement (more reliable)
- Clean up temp files after successful operations
- Fixes: File corruption due to failed mv command via lscpd
- Write content to /home/cyberpanel/scanner_temp_{scan_id}_{timestamp}.tmp first
- Use Python open() instead of shell here-document to avoid:
- lscpd connection reset for large files (>2KB)
- EOF_MARKER conflicts in file content
- Shell command size limits
- Copy temp file to user directory using executioner with user context
- Clean up CyberPanel temp file after copy
- Fixes: [Errno 104] Connection reset by peer when writing large files
- Add bypass check for 'content' field INSIDE isAPIEndpoint block
- Prevents blocking of legitimate JavaScript/PHP code in replace-file API
- Bypass list includes: content, fileContent, configData, rewriteRules, modSecRules
- Security check still applies to other fields in API requests
- Fixes: Replace-file API being blocked by security middleware
- executioner() returns 1 for success, 0 for failure (inverted)
- Fix mkdir check: if mkdir_result != 1 (was != 0)
- Fix cp check: if cp_result[0] != 1 (was != 0)
- Fix double slash in backup path by stripping trailing slash from wp_path
- Add logging to show mkdir_result value for debugging
- Add external_app field to AuthWrapper class
- Get externalApp from website object during authentication
- For FileAccessToken: Use Websites.externalApp
- For API Key: Use WPSites.owner.externalApp
- Update all 5 file operation endpoints to use file_token.external_app
- scanner_backup_file
- scanner_get_file
- scanner_replace_file
- scanner_rename_file
- scanner_delete_file
- Ensures externalApp matches wp_path since they come from same source
- Fixes backup API failing due to incorrect user context
Separate acme.sh certificate issuance and installation steps to ensure
domain configurations are properly stored. Previously, combining --issue
with --cert-file/--key-file/--fullchain-file in a single command caused
acme.sh to skip storing domain configs, breaking automatic renewals and
requiring manual certificate recreation for domain aliases.
