reuse the FileLogger module in append mode.
As it implements write, which is not thread safe (mutable self) and
we use it in a async context we need to serialize access using a
mutex.
Try to use the same format we do in pveproxy, namely the one which is
also used in apache or nginx by default.
Use the response extensions to pass up the userid, if we extract it
from a ticket.
The privileged and unprivileged dameons log both to the same file, to
have a unified view, and avoiding the need to handle more log files.
We avoid extra intra-process locking by reusing the fact that a write
smaller than PIPE_BUF (4k on linux) is atomic for files opened with
the 'O_APPEND' flag. For now the logged request path is not yet
guaranteed to be smaller than that, this will be improved in a future
patch.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Add a generous limit now and return the correct error (414 URI Too
Long). Otherwise we could to pretty larger GET requests, 64 KiB and
possible bigger (at 64 KiB my simple curl test failed due to
shell/curl limitations).
For now allow a 3072 characters as combined length of URI path and
query.
This is conform with the HTTP/1.1 RFCs (e.g., RFC 7231, 6.5.12 and
RFC 2616, 3.2.1) which do not specify any limits, upper or lower, but
require that all server accessible resources mus be reachable without
getting 414, which is normally fulfilled as we have various length
limits for stuff which could be in an URI, in place, e.g.:
* user id: max. 64 chars
* datastore: max. 32 chars
The only known problematic API endpoint is the catalog one, used in
the GUI's pxar file browser:
GET /api2/json/admin/datastore/<id>/catalog?..&filepath=<path>
The <path> is the encoded archive path, and can be arbitrary long.
But, this is a flawed design, as even without this new limit one can
easily generate archives which cannot be browsed anymore, as hyper
only accepts requests with max. 64 KiB in the URI.
So rather, we should move that to a GET-as-POST call, which has no
such limitations (and would not need to base32 encode the path).
Note: This change was inspired by adding a request access log, which
profits from such limits as we can then rely on certain atomicity
guarantees when writing requests to the log.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
needs new proxmox dependency to get the RpcEnvironment changes,
adding client_ip getter and setter.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The 'Ok::<_, Self::Error>(res)' type annotation was from a time where
we could not use async, and had a combinator here which needed
explicity type information. We switched over to async in commit
df52ba5e45 and, as the type annotation
is already included in the Future type, we can safely drop it.
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>
while we probably do not add much more to them, it still looks ugly.
If this was made so that adding a World readable API call is "hard"
and not done by accident, it rather should be done as a test on build
time. But, IMO, the API permission schema definitions are easy to
review, and not often changed/added - so any wrong World readable API
call will normally still caught.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Causes a panic if last_update is smaller than RRD_DATA_ENTRIES*reso,
which (I believe) can happen when inserting the first value for a DB.
Clamp the value to 0 in that case.
Signed-off-by: Stefan Reiter <s.reiter@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>
- remove chrono dependency
- depend on proxmox 0.3.8
- remove epoch_now, epoch_now_u64 and epoch_now_f64
- remove tm_editor (moved to proxmox crate)
- use new helpers from proxmox 0.3.8
* epoch_i64 and epoch_f64
* parse_rfc3339
* epoch_to_rfc3339_utc
* strftime_local
- BackupDir changes:
* store epoch and rfc3339 string instead of DateTime
* backup_time_to_string now return a Result
* remove unnecessary TryFrom<(BackupGroup, i64)> for BackupDir
- DynamicIndexHeader: change ctime to i64
- FixedIndexHeader: change ctime to i64
- remove chrono dependency
- depend on proxmox 0.3.8
- remove epoch_now, epoch_now_u64 and epoch_now_f64
- remove tm_editor (moved to proxmox crate)
- use new helpers from proxmox 0.3.8
* epoch_i64 and epoch_f64
* parse_rfc3339
* epoch_to_rfc3339_utc
* strftime_local
- BackupDir changes:
* store epoch and rfc3339 string instead of DateTime
* backup_time_to_string now return a Result
* remove unnecessary TryFrom<(BackupGroup, i64)> for BackupDir
- DynamicIndexHeader: change ctime to i64
- FixedIndexHeader: change ctime to i64
