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
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 c81417f267 , 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.
Although this 016f66cb46 was the correct fix for the auth sequence, other callers which search the database
with a static set of expressions are influenced by this as well.
To some degree it might be better to have different callers for this, but this increases the impact if the otherwise limited change.
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).
Ideally this should be refactored a bit to flush the configuration
regardless of enabled state, but the legacy code has no separate
template flush so it is tied to service (re)start and we are going
to leave it at a note.
Reshuffle the code a little to make it (a bit) more obvious this is
safe to assume and working confirmed by automatic mode already.
Since we have full control via MVC enable/disable this is fine now.
