Previously, errors in cloudflared socket handlers were silently swallowed
by empty catch blocks, making debugging difficult. This commit adds
proper error logging to all empty catch blocks in the cloudflared
socket handler to improve observability and debugging.
- Added error logging to join handler
- Added error logging to leave handler
- Added error logging to start handler
- Added error logging to removeToken handler
- Replace client.badssl.com tests with unit tests for parseTlsAlertNumber and getTlsAlertName
- Export helper functions for testing
- Keep one integration test for connection success scenario
Error messages could be translated, but TLS alert names (e.g., certificate_required)
are from RFC 8446 spec and should remain in English for consistency.
- Use i18n-t for description with code tag and RFC 8446 spec link
- Add comment that TLS alert names are from spec (not translatable)
- Refactor TCP monitor into smaller functions:
- checkTcp() for standard TCP connectivity check
- performStartTls() for STARTTLS handshake
- checkTlsCertificate() for TLS certificate validation
- attemptTlsConnection() for TLS connection with alert capture
- Improve error messages with more context
Per CommanderStorm's feedback, instead of creating a separate TLS monitor
type, add the TLS alert checking functionality directly to the existing
TCP monitor.
Changes:
- Add TLS_ALERT_CODES, parseTlsAlertNumber(), getTlsAlertName() to tcp.js
- Add checkTlsAlert() method to TCPMonitorType for mTLS verification
- Add 'Expected TLS Alert' dropdown to TCP monitor UI
- Remove separate TLS monitor type (tls.js)
This allows users to verify mTLS endpoints reject connections without
client certificates by expecting specific TLS alerts like
'certificate_required'.
Closes#5837
Add a new TLS monitor type that allows monitoring mTLS endpoints to verify
they properly reject connections without client certificates.
Features:
- New TLS monitor type with hostname and port configuration
- Expected TLS Alert dropdown to specify which TLS alert to expect
- Support for certificate_required (116) alert for mTLS verification
- Optional certificate expiry monitoring when connection succeeds
- Ignore TLS errors option
Closes#5837
Per CommanderStorm's feedback, refactor the check() method into:
- checkKeyword() - for legacy keyword matching
- checkJsonQuery() - for legacy JSONata query
- checkConditions() - for new conditions system
Also add test cases for MQTT conditions:
- Message condition with contains operator
- Topic condition with equals operator
- Condition mismatch rejection
- Multiple conditions with AND logic
This improves readability and maintainability.
Add rich conditions support to MQTT monitor similar to DNS monitor,
allowing users to define flexible conditions on:
- topic: The MQTT topic that received the message
- message: The raw message content
- json_value: JSONata-extracted value from JSON payloads
This provides a more intuitive and powerful way to validate MQTT
messages compared to the basic keyword/json-query checks.
Maintains backward compatibility with existing keyword and json-query
check types.
Closes#5992
Address review feedback from CommanderStorm to use the inherited
extractAddress() method instead of directly accessing monitorJSON["url"].
This properly handles different monitor types (ping, port, dns, etc.).
Add the monitored service URL as a clickable link in Google Chat
notifications, allowing users to quickly navigate to the affected
service for immediate investigation.
Closes#5952
Shaan