HTTP/HTTPS uptime monitors targeting LAN addresses (192.168.x.x,
10.x.x.x, 172.16.x.x) permanently reported 'down' on fresh installs
because SSRF protection rejects RFC 1918 ranges at two independent
checkpoints: the URL validator (DNS-resolution layer) and the safe
dialer (TCP-connect layer). Fixing only one layer leaves the monitor
broken in practice.
- Add IsRFC1918() predicate to the network package covering only the
three RFC 1918 CIDRs; 169.254.x.x (link-local / cloud metadata)
and loopback are intentionally excluded
- Add WithAllowRFC1918() functional option to both SafeHTTPClient and
ValidationConfig; option defaults to false so existing behaviour is
unchanged for every call site except uptime monitors
- In uptime_service.go, pass WithAllowRFC1918() to both
ValidateExternalURL and NewSafeHTTPClient together; a coordinating
comment documents that both layers must be relaxed as a unit
- 169.254.169.254 and the full 169.254.0.0/16 link-local range remain
unconditionally blocked; the cloud-metadata error path is preserved
- 21 new tests across three packages, including an explicit regression
guard that confirms RFC 1918 blocks are still applied without the
option set (TestValidateExternalURL_RFC1918BlockedByDefault)
Fixes issues 6 and 7 from the fresh-install bug report.
- The DB error return branch in SeedDefaultSecurityConfig was never
exercised because all seed tests only ran against a healthy in-memory
database; added a test that closes the underlying connection before
calling the function so the FirstOrCreate error path is reached
- The letsencrypt certificate cleanup loop in Register was unreachable
in all existing tests because no test pre-seeded a ProxyHost with
an letsencrypt cert association; added a test that creates that
precondition so the log and Update lines inside the loop execute
- These were the last two files blocking patch coverage on PR #852
- The security config Upsert update path copied all rate limit fields
from the incoming request onto the existing database record except
RateLimitMode, so the seeded default value of "disabled" always
survived a POST regardless of what the caller sent
- This silently prevented the Caddy rate_limit handler from being
injected on any container with a pre-existing config record (i.e.,
every real deployment and every CI run after migration)
- Added the missing field assignment so RateLimitMode is correctly
persisted on update alongside all other rate limit settings
- Integration test payload now also sends rate_limit_enable alongside
rate_limit_mode so the handler sync logic fires via its explicit
first branch, providing belt-and-suspenders correctness independent
of which path the caller uses to express intent
On a fresh install the security_configs table is auto-migrated but
contains no rows. Any code path reading SecurityConfig by name received
an empty Go struct with zero values, producing an all-disabled UI state
that offered no guidance to the user and made the security status
endpoint appear broken.
Adds a SeedDefaultSecurityConfig function that uses FirstOrCreate to
guarantee a default row exists with safe, disabled-by-default values on
every startup. The call is idempotent — existing rows are never modified,
so upgrades are unaffected. If the seed fails the application logs a
warning and continues rather than crashing.
Zero-valued rate-limit fields are intentional and safe: the Cerberus
rate-limit middleware applies hardcoded fallback thresholds when the
stored values are zero, so enabling rate limiting without configuring
thresholds results in sensible defaults rather than a divide-by-zero or
traffic block.
Adds three unit tests covering the empty-database, idempotent, and
do-not-overwrite-existing paths.
- Updated the list of supported notification provider types to include 'pushover'.
- Enhanced the notifications API tests to validate Pushover integration.
- Modified the notifications form to include fields specific to Pushover, such as API Token and User Key.
- Implemented CRUD operations for Pushover providers in the settings.
- Added end-to-end tests for Pushover provider functionality, including form rendering, payload validation, and security checks.
- Updated translations to include Pushover-specific labels and placeholders.
The slack sub-tests in TestDiscordOnly_CreateRejectsNonDiscord and
TestBlocker3_CreateProviderRejectsNonDiscordWithSecurityEvents were
omitting the required token field from their request payloads.
CreateProvider enforces that Slack providers must have a non-empty
token (the webhook URL) at creation time. Without it the service
returns "slack webhook URL is required", which the handler does not
classify as a 400 validation error, so it falls through to 500.
Add a token field to each test struct, populate it for the slack
case with a valid-format Slack webhook URL, and use
WithSlackURLValidator to bypass the real format check in unit tests —
matching the pattern used in all existing service-level Slack tests.
- Expanded fetchSessionUser to include Bearer token from localStorage as a fallback for authentication when Secure cookies fail.
- Updated headers to conditionally include Authorization if a token is present.
- Ensured compatibility with the recent fix for the Secure cookie flag on private network connections.
- Updated the notification provider types to include 'slack'.
- Modified API tests to handle 'slack' as a valid provider type.
- Enhanced frontend forms to display Slack-specific fields (webhook URL and channel name).
- Implemented CRUD operations for Slack providers, ensuring proper payload structure.
- Added E2E tests for Slack notification provider, covering form rendering, validation, and security checks.
- Updated translations to include Slack-related text.
- Ensured that sensitive information (like tokens) is not exposed in API responses.
- Updated API to support Telegram as a notification provider type.
- Enhanced tests to cover Telegram provider creation, updates, and token handling.
- Modified frontend forms to include Telegram-specific fields and validation.
- Added localization strings for Telegram provider.
- Implemented security measures to ensure bot tokens are not exposed in API responses.
- Implemented email notification functionality in the NotificationService.
- Added support for rendering email templates based on event types.
- Created HTML templates for various notification types (security alerts, SSL events, uptime events, and system events).
- Updated the dispatchEmail method to utilize the new email templates.
- Added tests for email template rendering and fallback mechanisms.
- Enhanced documentation to include email notification setup and usage instructions.
- Introduced end-to-end tests for the email notification provider in the settings.
Unifies the two previously independent email subsystems — MailService
(net/smtp transport) and NotificationService (HTTP-based providers) —
so email can participate in the notification dispatch pipeline.
Key changes:
- SendEmail signature updated to accept context.Context and []string
recipients to enable timeout propagation and multi-recipient dispatch
- NotificationService.dispatchEmail() wires MailService as a first-class
provider type with IsConfigured() guard and 30s context timeout
- 'email' added to isSupportedNotificationProviderType() and
supportsJSONTemplates() returns false for email (plain/HTML only)
- settings_handler.go test-email endpoint updated to new SendEmail API
- Frontend: 'email' added to provider type union in notifications.ts,
Notifications.tsx shows recipient field and hides URL/token fields for
email providers
- All existing tests updated to match new SendEmail signature
- New tests added covering dispatchEmail paths, IsConfigured guards,
recipient validation, and context timeout behaviour
Also fixes confirmed false-positive CodeQL go/email-injection alerts:
- smtp.SendMail, sendSSL w.Write, and sendSTARTTLS w.Write sites now
carry inline codeql[go/email-injection] annotations as required by the
CodeQL same-line suppression spec; preceding-line annotations silently
no-op in current CodeQL versions
- auth_handler.go c.SetCookie annotated for intentional Secure=false on
local non-HTTPS loopback (go/cookie-secure-not-set warning only)
Closes part of #800
The test used a 5ms TTL with a 10ms wall-clock sleep to simulate cache
expiry. On loaded CI runners (Azure eastus), the repull HTTP round-trip
plus disk I/O for Store easily exceeded 5ms, causing the freshly written
cache entry to also appear expired when Load was called immediately after,
producing a spurious 'cache expired' error.
HubCache already exposes a nowFn field for deterministic time injection.
Replace the sleep-based approach with a nowFn that advances the clock 2
hours, making the initial entry appear expired to Apply while keeping the
freshly re-stored entry (retrieved_at ≈ now+2h, TTL=1h) valid for the
final assertion.
Two unit tests cover the code paths introduced when email was registered
as a recognised notification provider type in Stage 2.
- TestSendExternal_EmailProviderSkipsJSONTemplate exercises the goroutine
warn path where an enabled email provider passes isDispatchEnabled but
fails supportsJSONTemplates, producing a warning log without panicking
- TestTestProvider_EmailRejectsJSONTemplateStep asserts TestProvider
returns a clear error for email providers because the JSON template
dispatch path does not apply to email delivery
Patch coverage: 6/6 changed lines covered (100%)
After email was recognised as a supported provider type, the existing
rejection assertion for unsupported types incorrectly included email
in its denial list, causing a nil-dereference panic.
- Remove email from the unsupported-type rejection list and cover it
in the accepted-types path instead
- Correct allFeaturesEnabled fixture to set email flag to true, keeping
the fixture semantically consistent with all other service flags
Add email as a recognized, feature-flagged notification service type.
The flag defaults to false and acts as a dispatch gate alongside the
existing discord, gotify, and webhook notification service flags.
- Add FlagEmailServiceEnabled constant to the notifications feature flag
registry with the canonical key convention
- Register the flag in the handler defaults so it appears in the feature
flags API response with a false default
- Recognise 'email' as a supported notification provider type so that
providers of this type pass the type validation gate
- Gate email dispatch on the new flag in isDispatchEnabled() following
the same pattern as gotify and webhook service flags
- Expand the E2E test fixtures FeatureFlags interface to include the new
flag key so typed fixture objects remain accurate
No email message dispatch is wired in this commit; the flag registration
alone makes the email provider type valid and toggleable.
Remove all deprecated Shoutrrr integration artifacts and dead legacy fallback
code from the notification subsystem.
- Remove legacySendFunc field, ErrLegacyFallbackDisabled error, and
legacyFallbackInvocationError() from notification service
- Delete ShouldUseLegacyFallback() from notification router; simplify
ShouldUseNotify() by removing now-dead providerEngine parameter
- Remove EngineLegacy engine constant; EngineNotifyV1 is the sole engine
- Remove legacy.fallback_enabled feature flag, retiredLegacyFallbackEnvAliases,
and parseFlagBool/resolveRetiredLegacyFallback helpers from flags handler
- Remove orphaned EmailRecipients field from NotificationConfig model
- Delete feature_flags_coverage_v2_test.go (tested only the retired flag path)
- Delete security_notifications_test.go.archived (stale archived file)
- Move FIREFOX_E2E_FIXES_SUMMARY.md to docs/implementation/
- Remove root-level scan artifacts tracked in error; add gitignore patterns to
prevent future tracking of trivy-report.json and related outputs
- Update ARCHITECTURE.instructions.md: Notifications row Shoutrrr → Notify
No functional changes to active notification dispatch or mail delivery.
- Implemented middleware to restrict access for passthrough users in management routes.
- Added unit tests for management access requirements based on user roles.
- Updated user model tests to include passthrough role validation.
- Enhanced frontend user management to support passthrough role in invite modal.
- Created end-to-end tests for passthrough user access restrictions and navigation visibility.
- Verified self-service profile management for admins and regular users.
- Wrapped the Settings component in RequireRole to enforce access control for admin and user roles.
- Introduced a new custom hook `useFocusTrap` to manage focus within modal dialogs, enhancing accessibility.
- Applied the focus trap in InviteModal, PermissionsModal, and UserDetailModal to prevent focus from leaving the dialog.
- Updated PassthroughLanding to focus on the heading when the component mounts.
