IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
API tokens between rust & perl code bases are inconsistent... this
needs fixing, but for now this is faster and more compatible.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Fixes the following clippy warnings:
warning: the borrowed expression implements the required traits
--> proxmox-tfa/src/api/recovery.rs:86:24
|
86 | Ok(hex::encode(&hmac))
| ^^^^^ help: change this to: `hmac`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_borrows_for_generic_args
and
warning: this expression creates a reference which is immediately dereferenced by the compiler
--> proxmox-network-api/src/api_impl.rs:108:47
|
108 | interface.set_bond_slave_list(&slaves)?;
| ^^^^^^^ help: change this to: `slaves`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_borrow
= note: `#[warn(clippy::needless_borrow)]` on by default
Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
previously we changed the internal type of the 'data' property
from Option<T> to T in the assumption the api always returns
'data:null'.
this is actually only the case when the api call succeeds. in an error
case there is no data property at all.
to fix this issue while behaving the same for 'data:null' we have to
revert to Option<T> for RawApiResponse but instead of always throwing an
error for 'data:null' in 'check' we now try there to deserialize from
Value::Null for T if there was no data. This will succeed for the Type
'()' which was the motivation for the original change.
The only downside is that the RawApiResponse now has a trait bound that
T is deserializeable, but was a requirement for using it anyway
(as there was no other way of constructing it)
Fixes: 271a55f ("client: remove option from inner RawApiResponse")
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
when using the client for an api call that does not return any data
(it returns '{"data":null}'), we would always get an error 'api returned
no data'. The message is technically correct, but it should not be an
error when we expect no data (e.g. most of our CRUD PUT/POST calls)
instead of having the Option<T> in the RawApiResponse type itself, move
it into to the 'nodata' function intended for api calls where we don't
expect any data.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Since the WASM client cannot actually use a `http::Request` the way we
expect it to, that is, it cannot manually along cookies, we turn the
client bit inside out:
This crate mainly defines the `HttpApiClient` trait which expects the
http client to perform *authenticated* API calls, that is, the
handling of API tokens and tickets should happen at the *implementor*
side.
The product clients will require *this* trait to be implemented, and
will not themselves offer a way to login.
As for the `Client` struct, this will now instead *implement* this
trait and will *not* be used in the `wasm` ecosystem. Rather, this is
the ticket handling http client that already exists in the PWT based
ui code.
The PVE client in `pve-api-types` will not *contain* a `Client`
anymore, but rather, it will provide PVE api call implementations for
something implementing `HttpApiClient`.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
The environment trait was useful on the CLI, but does not really
translate well to eg. the wasm ui (or pdm for that matter), so drop it
and instead have `.login` and `.login_tfa` just take the
`proxmox_login` type and handle the updating of authentication data.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Because we ultimately also want to drop the `Environment` trait since
it is not suitable for all use cases (eg. wasm ui)
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
To see if it is even still necessary given that it's not a trait
object type where auto traits would need to be explicit...
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
This should be moved to where we actually need it, not be part of the
generic product client.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
