Allowed IPs take the full settings reload after a write #42

Merged

jcoffey-dev merged 1 commits from fix/allowed-ip-reload into main

2026-09-24 20:33:19 +00:00

jcoffey-dev commented

2026-09-24 20:20:57 +00:00

Owner

Problem

write_reload_target (crates/common/src/cache/reload.rs:268, from #39) sends an AllowedIp write to the blocked-IP reload.

That reload (reload.rs:95-99) only rebuilds BlockedIps. Allowed IPs are parsed in Security::parse (crates/common/src/network/security.rs:83) into core.network.security, and only a full settings reload rebuilds that.

The result: after an AllowedIp write, the response says x:settingsReload: {"applied": true}, but is_ip_allowed doesn't see the change until some later full reload.

Change

AllowedIp now maps to the full settings reload, the same one ordinary settings objects get. BlockedIp keeps its targeted reload.

Tests

system::auto_reload::settings_reload_tests (RocksDb) now also:

Creates an allowed IP over JMAP and checks is_ip_allowed sees it with no ReloadSettings, and that the response reports it applied.
Destroys it and checks it's gone again.

Results:

With this change: pass.
With main's reload.rs: fails ("allowed IP not in the running settings").
system::system_tests (RocksDb), which includes the security tests: pass.

Admin UI

inbuxa-admin PR #16 works around this by always sending ReloadSettings after an AllowedIp save. Once a server release includes this fix, that exception can go.

## Problem `write_reload_target` (`crates/common/src/cache/reload.rs:268`, from #39) sends an `AllowedIp` write to the blocked-IP reload. That reload (`reload.rs:95-99`) only rebuilds `BlockedIps`. Allowed IPs are parsed in `Security::parse` (`crates/common/src/network/security.rs:83`) into `core.network.security`, and only a full settings reload rebuilds that. The result: after an `AllowedIp` write, the response says `x:settingsReload: {"applied": true}`, but `is_ip_allowed` doesn't see the change until some later full reload. ## Change `AllowedIp` now maps to the full settings reload, the same one ordinary settings objects get. `BlockedIp` keeps its targeted reload. ## Tests `system::auto_reload::settings_reload_tests` (RocksDb) now also: 1. Creates an allowed IP over JMAP and checks `is_ip_allowed` sees it with no `ReloadSettings`, and that the response reports it applied. 2. Destroys it and checks it's gone again. Results: - With this change: pass. - With `main`'s `reload.rs`: fails ("allowed IP not in the running settings"). - `system::system_tests` (RocksDb), which includes the security tests: pass. ## Admin UI inbuxa-admin PR #16 works around this by always sending `ReloadSettings` after an `AllowedIp` save. Once a server release includes this fix, that exception can go.

jcoffey-dev added 1 commit 2026-09-24 20:20:57 +00:00

Allowed IPs take the full settings reload after a write

ci / build (pull_request) Successful in 11m59s

Details

ci / fork-checks (pull_request) Successful in 45s

Details

fcef4b1c3f

write_reload_target sent AllowedIp writes to the blocked-IP reload, but
that reload rebuilds only BlockedIps. Allowed IPs are parsed into the
core's security settings (Security::parse), which only a full reload
rebuilds, so an AllowedIp write reported x:settingsReload applied: true
while the change wasn't live until the next full reload.

AllowedIp now maps to the full reload, like the other settings objects;
BlockedIp keeps its targeted reload.

system::auto_reload::settings_reload_tests now creates an allowed IP
over JMAP and checks that is_ip_allowed sees it with no ReloadSettings,
and that destroying it takes it out again. On main it fails ("allowed
IP not in the running settings").

jcoffey-dev merged commit d86e7639ac into main

2026-09-24 20:33:19 +00:00

jcoffey-dev deleted branch fix/allowed-ip-reload

2026-09-24 20:33:19 +00:00

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: inbuxa/inbuxa-server#42