we can easily go beyond that when having long datastore/remote names
also because we do 'systemd-encode' them, which means that every special
char takes up 4 bytes (e.g. '-' => '\x2d')
while we could just increase the lenght to say 256 or 512, i do not
really see the benefit to limit this at all, since users cannot create
tasks with arbitrary names, and all other fields are generated from
other valid types (username, datastore, remote, etc.)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
In order to avoid name conflicts with WorkerTaskContext
- renamed WorkerTask::log to WorkerTask::log_message
Note: Methods have different fuction signatures
Also renamed WorkerTask::warn to WorkerTask::log_warning for
consistency reasons.
Use the task_log!() and task_warn!() macros more often.
it's not immediately obvious that they can be specified more than once
otherwise.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
this is only used for CLI synopsis/usage strings, the API viewer already
prints the full type text in a correct format. the old variant was also
rather misleading, since on the CLI we don't pass in an array, but each
item as its own parameter.
noticed this while working on the pull/sync filtering series, but it
affects quite a lot of stuff, among other things the Updater and
Deleteable CLI, e.g. from `man proxmox-backup-manager`:
> --delete <array>
> List of properties to delete.
vs.
> --delete disable|validation-delay
> List of properties to delete.
But some of them might only have <string> as the item type text,
which is not much nicer but also not really worse.
The whole "List of .." is confusing anyway, but not easily solvable,
since the description is used for
- API dump/viewer (where it is a list/array of ..)
- usage message/man pages (where it's a parameter that gives a single
element, but it might be passed in multiple times to construct an
array)
Also, for some common occurrences, the item description is too
generic, and it's not possible to override the description for
external types with the current api macro.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
[ Thomas: Added more context that was in the diffstat of the path ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Handle auth logs the same way as access log.
- Configure with ApiConfig
- CommandoSocket command to reload auth-logs "api-auth-log-reopen"
Inside API calls, we now access the ApiConfig using the RestEnvironment.
The openid_login api now also logs failed logins and return http_err!(UNAUTHORIZED, ..)
on failed logins.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This need impl UserInformation for Arc<CachedUserInfo> which is implemented
with proxmox 0.13.2
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
ApiConfig: avoid using pbs_config::backup_user()
CommandoSocket: avoid using pbs_config::backup_user()
FileLogger: avoid using pbs_config::backup_user()
- use atomic_open_or_create_file()
Auth Trait: moved definitions to proxmox-rest-server/src/lib.rs
- removed CachedUserInfo patrameter
- return user as String (not Authid)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
this prevents us from using it under certain conditions and it's
actually not necessary, so drop them
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
* Updatable is now named UpdaterType
* UPDATER_IS_OPTION is now assumed to always be true
While an updater can be a non-optional struct, being an
updater, all its fields are also Updaters, so after
expanding all levels of nesting, the resulting list of
fields can only contain optional values.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
This way we can assign `API_SCHEMA` constants to `Option`
types.
Here's why:
The api-macro generated code usese `T::API_SCHEMA` when
building ObjectSchemas.
For Updaters we replace `T` with
`<T as Updatable>::Updater`
This means for "simple" wrappers like our `Authid` or
`Userid`, the ObjectSchema will try to refer to
`<Authid as Updatable>::Updater::API_SCHEMA`
which resolves to:
`Option<Authid>::API_SCHEMA`
which does not exist, for which we cannot add a normal
`impl` block to add the schema variable, since `Option` is
not "ours".
But we now have a blanket implementation of `ApiType` for
`Option<T> where T: ApiType` which just points to the
original `T::API_SCHEMA`.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
