captive portal: regression in 369630d, allowed addresses missing from session ips
If a client is allowed through a statically configured IP, the MAC
becomes secondary, but in the roaming case the set of actual IPs
relied on the MAC address. Since a statically configured IP may not
have a MAC active at a given time, but we do want to keep this IP in
the captive portal pf zone at all time, we merge the primary IP
with the roaming IPs. As a set this will deduplicate automatically.
While here, no MAC address lookup was performed in the case of a
static IP, add it here so it can be actively seen in the sessions
GUI.
Closes https://github.com/opnsense/core/issues/10124
(cherry picked from commit 2b43ee5b87948347ac5a704c484001d169f059e4)
captive portal: regression in 369630d, allowed addresses missing from session ips
If a client is allowed through a statically configured IP, the MAC
becomes secondary, but in the roaming case the set of actual IPs
relied on the MAC address. Since a statically configured IP may not
have a MAC active at a given time, but we do want to keep this IP in
the captive portal pf zone at all time, we merge the primary IP
with the roaming IPs. As a set this will deduplicate automatically.
While here, no MAC address lookup was performed in the case of a
static IP, add it here so it can be actively seen in the sessions
GUI.
Closes https://github.com/opnsense/core/issues/10124
Services: Kea DHCP: Kea DHCPv6 - fix "Delegated length must be longer than or equal to prefix length" validation, closes https://github.com/opnsense/core/issues/10146
While here, also fix a prefix validation (when x::/64 is specified for example).
Firewall: Rules [new] - refactor searchRuleAction() to use the same filtering and sorting logic on MVC and legacy data.
The current implementation is applying our filter logic twice for MVC records, first it uses the default searchBase() construct, which it then needs to pipe through searchRecordsetBase() again. There are a couple of downsides here, it's more expensive (although the user likely won't notice), but also requires duplication of filter logic.
With the logic introduced in https://github.com/opnsense/core/commit/c81417f26747a9e4e46f608c2791bbae805e79fd , we can extract the exact same content from our model so we can merge all at once and push it through our filtering and sorting logic.
The idea is to be able to "smarten" searchRecordsetBase() a bit so we can apply some additional logic based on types at some point in time, which requires all data to passthrough the same pipeline at least.
This commit should be backwards compatible with the previous code.
System: Access: Servers - RADIUS, implement NAS-IP-Address attribute. closes https://github.com/opnsense/core/pull/10089
Refactor PR a bit and implement the requested attribute.
For existing setups, the send attributes should be unchanged.
system: more natural cron escaping for command #10075
Changes command output from
/usr/local/sbin/configctl -d -- 'system remote backup'
to
/usr/local/sbin/configctl -d -- system remote backup
which is actually correct and needed since c491376.
Not sure what "\n" had to do with it but in the case of the
command it should be a normal string and risk of injection
is lower than parameter (but still mitigated properly).
MVC: add support for pluggable dynamic menu items and move some existing parts out of the MenuSystem class
In most cases we use static menu registartions, but there are exceptions which depend on interfaces for example.
While looking at https://github.com/opnsense/core/pull/10033, a longer standing wish came up again, which is the reason to add this support right now. It also helps in removing some legacy components for good via plugins.
To register new menu items, the following pattern may be used:
* In your model, derive a Menu class from MenuContainer
* implement a method collect() which should add new menu items via the appendItem() {bound to appendItem in MenuSystem}
Always try to minimize the amount of code inside these plugins as this code will be executed on each page load.
