This is similar to what we have in PVE and PMG now. Will be used to
set the real client IP for proxied connections.
with a dummy implementation, which avoids the need to implement it
for the CLI or Backup environments, which do not have or care for a
client IP
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
We only used this for the privileges for now, and there it's a
nuisance to alter all bit definitions manually if something is added.
This change makes it count the bits up automatically.
Rename the macro to indicate that this is not a generic name map but
a more specific named bit mapping.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
by disallowing [] around ipv4 adresses (which is not very common)
we did not use this anywhere, so there should not be any compatibility
problem
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
after benchmarking (again), i found that doing a simple find instead
of saving the inidices for the ident strings in a hashmap has
no real performance impact (the max list size for the properties
are max ~25 at the moment, so this should not be impacting compile
times much) but it is much simpler
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
to safely differentiate between checking
- the current user matches some static string
- the current user matches the value in some (path) parameter.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
by replacing more characters ('.','+') by '_' and prefix them when
it starts with a number
we sometimes need to parse such fields, e.g in serde attributes like
#[serde(rename = "802.3ad")]
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
the 'properties_' list is sorted by the the literal string of a
fieldname, but we binary-search for the 'ident_str' (which may be
different, since we map '-' to '_' for example)
by creating a hashmap to map from ident to index, we can do a simple
lookup in that case that will work
benchmarks showed no measurable performance difference
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
mainly so we notice if this assumption does not hold for some platform
or changes in the future.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
strftime(3) does not mention this explicitly, but years before 1000 have
their leading zero(es) stripped, which is not valid according to either
ISO-8601 or its profile RFC3339.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
mktime/timegm can modify the timestruct (to normalize the time, e.g.
convert the january 40 to february 9)
to use that feature, we have to give a mutable reference, else the
struct will be copied and the original left untouched
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
