Fixes a regression from commit f50a627f34
which resulted in re-using the prefix without sub-commands when calling
handle_simple_command(_future)
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
since it does no longer store just a userid, but potentially an API
token identifier as well
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Instead of setting a default value to a const and inside an
.unwrap_or_else closure, lets set it only to the const and reuse that
later in .unwrap_or
To achieve that we move the "unrwap_or" code for param plumbing code generation
a bit later so that we have easy access to the generated const name.
As all this code is related to optional/default-value stuff it does read still
relatively OK with that change, IMO.
This has the advantage of not getting a warning like:
> warning: constant is never used: `API_METHOD_EXAMPLE_FOO_PARAM_DEFAULT_FORCE`
> --> src/api2/node/foo.rs
> |
> XY | force: {
> | ^^^^^
> = note: `#[warn(dead_code)]` on by default
When one has a API endpoint like:
> #[api(
> input: {
> properties: {
> force: {
> type: bool,
> optional: true,
> default: false,
> },
> },
> },
> ...
> )]
> /// Example
> fn example_foo(force: bool) -> Result<(), Error> {
> if force {
> // do something
> }
> Ok(())
> }
It effectively changes the output for optional parameters with a default set
and no Option<T> from
> let p = p.unwrap_or_else(|| #default_value);
to
> let p = p.unwrap_or(#const_name_for_default);
where the "#const_name_for_default" is a pub const with value
"#default_value"
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
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>
