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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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>
In the uncommon circumstance that calls to `read()` end up reading any number of
bytes other than 4096, the subsequently read bytes become misaligned, causing
blocks of zeroes to be written unnecessarily.
To illustrate, imagine you have a 12KiB file:
[x][x][x][x][ ][ ][ ][ ][x][x][x][x]
└──4096──┘ └──4096──┘ └──4096──┘
The first and last block are filled with some data, whereas the middle block is
empty and will therefore result in only zeroes being read.
In order for the empty block to be skipped with `seek()`, the entire buffer has
to be filled with zeroes.
If, for example, the first `read()` ends up putting only 3KiB into the buffer,
the empty block in the middle won't be detected properly, as the buffer will
now always contain some data. What results are four misaligned reads:
[x][x][x][x][ ][ ][ ][ ][x][x][x][x]
├─────┘ ├────────┘ ├────────┘ │
1 2 3 4
This is fixed by ensuring chunks of 4KiB are always read into the buffer,
except when the last block is truncated. In order to prevent frequent small
reads, the incoming reader is also buffered via `io::BufReader`.
Signed-off-by: Max Carrara <m.carrara@proxmox.com>
this should avoid most common size limitations. the search should also
complete quicker as fewer results need to be computed. note that this
way a configuration may be accepted, but the related sync job can
fail due to and exceeded size limit warning for some ldap servers
(such as 2.5.14+dfsg-0ubuntu0.22.04.2).
Signed-off-by: Stefan Sterz <s.sterz@proxmox.com>
Dropping a copy leaves the original intact
See:
https://rust-lang.github.io/rust-clippy/master/index.html#drop_copy
I assume the `drop` was used to silence a 'unused variable' warning,
so I silenced it by other means.
Signed-off-by: Lukas Wagner <l.wagner@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>
we have use cases where we have bytes, and serde_json has a from_slice
method, doing the utf-8 check unnecessarily is pointless, while going
from &str to &[u8] is free...
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
