this fixes intra document links or rephrases the documentation in a
more appropriate way to remove all `broken_intra_doc_links` warnings.
Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
if the client knows the auth cookie's name, it now passes it on to the
relevant parts of `proxmox-login` so that the ticket is send the
correct cookie
Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
this should make it possible to use the proxmox-client crate outside
of context where HttpOnly cookies are handled for us. if a cookie
name is provided to a client, it tries to find a corresponding
`Set-Cookie` header in the login response and passes tries to parse
it as a ticket. that ticket is then passed on to proxmox-login like
any regular ticket.
Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
Fixes a style issue introduced by b31ab119 ("client: improve api error
message (avoid duplicate status code)"), as one always should use
inline variables for format template strings even if there are some
that cannot be used, e.g. as some method needs to be called on them
like here. The reason for this is to reduce the amount of
free-standing "{}" and parameters as that reduces the need to manually
match what "{}" resolves to which expression. While it is not that bad
for only two format variables it's still not winning us anything if we
don't do it and breaks consistency with newer code style.
Noticed as that commit made the line overly long, causing rustfmt
changing the line.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The 'Anyhow' error is not useful and meant for throw-away errors which
cannot be dealt with anyway, and we'd like to be able to tell apart
network problems from actual HTTP responses, so that we can
potentially try a different node in a cluster connection.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
The get/put/post/put_without_body/... methods now have a default
implementation forwarding to a generic `request` method as all our
implementations do the same already anyway.
Additionally, in order to allow easy access to a "streaming body", the
Body type is now exposed.
In the future, this crate may also require a wrapper to standardize
the handling of `application/json-seq` streams if we end up using
them, but for now, a simple way to expose the body is enough to get
going.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
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>
