Borderage Core

Contact BorderAge at borderage@needemand.com or visit borderage.com to obtain your site_id and site_secret_key.

Already-verified visitors (with valid cookies) can still access protected pages. New visitors will see the verification page but won't be able to complete verification until credits are replenished. You can configure automatic email alerts in the Protection tab to notify you when credits fall below a threshold (default: 100).

No. BorderAge uses hand gesture recognition only. Visitors wave their hand to verify their age - no selfie, no ID document, no facial data.

This plugin is a tool to assist with age verification. Compliance with applicable laws depends on your jurisdiction and implementation. Consult legal counsel for compliance advice.

BorderAge Core includes a multi-layer security system to protect against abuse: Token-Based Protection:

1. Token Creation - When a visitor starts verification, a unique one-time token is created in the database
2. BorderAge Callback - The API returns a callback URL. The plugin validates the token exists and hasn't been used yet
3. Token Consumption - If valid, the token is marked as used and the visitor can create an account
4. Expiration - Tokens expire after 5 minutes or 24 hours (for cleanup)

1. Attempt Tracking - Each verification attempt generates a unique reference ID
2. Configurable Limits - Set max attempts (default: 1) and time window in hours (default: 24)
3. Enforcement - When limit is exceeded, visitors see a 429 error page
4. Automatic Cleanup - Old attempts are removed after the time window expires

1. Single Login Form - Visitors use one login form from the verification page
2. Dual Authentication Order - Plugin checks WordPress credentials first, then falls back to visitor account credentials
3. Login Attempt Tracking - Failed login attempts are rate-limited with anonymized references
4. Privacy by Design - No IP address is stored in the database for login rate limiting

• Prevents callback URL sharing and account fraud
• One-time tokens eliminate reuse attempts
• Rate limiting prevents brute force verification attempts
• Hash verification ensures callback authenticity
• Automatic cleanup prevents stale data
• Transparent to users - seamless experience
• GDPR/CNIL compliant - no IP addresses or personal data stored

The credit alert system automatically notifies you when your BorderAge credit balance falls below a configured threshold:

• Configuration: Set alert threshold (default: 100 credits) in BorderAge > Protection
• Email Setup: Enter your notification email address
• Enable/Disable: Toggle credit alerts on or off
• Daily Checks: A cron job checks your balance once per day
• Duplicate Prevention: Only one alert sent per low-balance period
• Test Email: Send a test email to verify your configuration

Rate limiting prevents brute force verification attempts by limiting the number of verification attempts a visitor can make within a configured time period:

• Default Settings: 1 attempt per 24 hours
• Customizable: Adjust max attempts and time window in Protection tab
• How it Works: Each attempt is tracked by visitor. When limit is exceeded, a 429 error page is displayed
• Reference Tracking: Unique reference IDs are generated for failed attempts
• Protection: Prevents automated verification attempts and abuse

The Developer Tools tab (BorderAge > Dev Tools) provides testing utilities:

• Reset Visitor Data: Clear all visitor accounts and verification cookies
• Reset Callback Logs: Remove all verification callback records
• Clear Health Logs: Delete internal health monitoring logs
• Debug Mode Only: These tools are only available when debug mode is enabled

Enable Debug Mode in BorderAge > Configuration, then use these tools:

• Health Logs: View in BorderAge > Debug tab - shows system events and errors
• Export Debug Info: Download complete debug dump as JSON
• Developer Tools: Reset testing data and clear logs in Dev Tools tab
• Callback Logs: View verification callback attempts in database
• Health Log Export: Export logs to CSV for analysis

Health logs provide internal system monitoring for troubleshooting:

• Location: Stored in protected JSON files with .htaccess
• Format: JSON with timestamp, level, message, and context
• Log Levels: info, warning, error, api, callback, debug
• Retention: Automatically cleaned up after 24 hours
• Privacy: Sensitive data is masked in logs
• Access: View via BorderAge > Debug tab
• Export: Download as JSON or CSV for external analysis

Pretty permalinks are required for the verification callback URL to function correctly:

• Technical Reason: The callback endpoint requires URL rewriting
• Impact: Without pretty permalinks, verification callbacks fail
• Setup: Go to Settings > Permalinks, select any option except "Plain"
• Verification: An admin notice will alert you if permalinks are incompatible
• Server Requirement: Requires mod_rewrite on Apache or rewrite rules on Nginx

The Statistics dashboard (BorderAge > Statistics) displays verification metrics:

• Total Verifications: Count of all completed verifications
• Adult/Minor Breakdown: Number of visitors verified as adults vs minors
• Monthly Statistics: Verification trends over time
• Data Source: Retrieved from BorderAge API
• Caching: Data cached for 10 minutes to reduce API calls
• Debug Mode: Displays mock data for testing without API access

The visitor account system provides a convenient way for returning visitors to avoid repeated verification:

• Account Creation: Optional after successful verification
• Login-based Access: Logged-in visitors bypass verification
• Cookie Fallback: Unregistered visitors remembered via cookies (24h)
• Credentials: Email and hashed password stored securely
• Integration: Works with WordPress user system

The plugin provides one unified login entry point for two account types: WordPress users (admins/editors/members) and BorderAge visitor accounts. Using wp_signon() is technically necessary because WordPress users must be authenticated by WordPress itself, not by plugin-specific password logic. Why this uses WordPress core authentication instead of custom verification:

• Core password handling - uses WordPress native hashing and authentication flow
• Session compatibility - keeps standard WordPress auth cookies and login state
• Role and capability continuity - existing WordPress roles are preserved without custom mapping
• Pluggable ecosystem support - remains compatible with plugins relying on WordPress auth hooks
• Reduced security surface - avoids duplicating sensitive credential logic in plugin code

• POST-only processing - non-POST requests are rejected
• Nonce verification - borderage_visitor_login must be valid before authentication
• Input hardening - login and redirect input are normalized/sanitized
• Safe redirect handling - redirect target is validated before use
• Login rate limiting - failed attempts are throttled with anonymized references (no IP storage)
• No long-lived guest-flow sessions - remember => false disables persistent "remember me" cookies in this flow
• HTTPS-aware cookie behavior - is_ssl() aligns auth cookie security with the current transport context