a previous commit fixed up all intra doc links that were present on
public apis, this also fixes the links for private members.
Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
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>
this panics when running `cargo test` otherwise, as the api macro
requires fields in `ObjectSchema`s to be sorted now.
Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
commit 68b13965 (router: docs: add horizontal line before nested
command docs) broke the nested command group test case. this commit
adapts the expected output accordingly.
Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
while the lint is correct about how these enum members should be
capitalized, the enum is marked as `pub` and all users of it would
need to adapt. so ignore the lint for now [1].
[1]:
https://rust-lang.github.io/rust-clippy/master/index.html#upper_case_acronyms
Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
while this is a reasonable convention to follow, in this case the new
function is part of a public trait and changing the signature would
force all users to adapt. so ignore the lint for now [1].
[1]:
https://rust-lang.github.io/rust-clippy/master/index.html#new_ret_no_self
Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
while the function would be more useful as pointed out by the clippy
lint, it i currently `pub` and users of the function would need to
adapt to the change here. so ignore the lint for now.
[1]: https://rust-lang.github.io/rust-clippy/master/index.html#ptr_arg
Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
the `type_complexity` clippy lint [1] is intended to make the code
more legible in most cases. however, the lint triggers on a member of
a private enum, an example minimal rest server and a private static
variable here. so the benefits of declaring a new type that would
encapsulate this complexity is minimal. hence, ignore the warnings for
now.
[1]:
https://rust-lang.github.io/rust-clippy/master/index.html#type_complexity
Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
the `ApiHandler`'s `PartialEq` implementation makes heavy use of
`transmute`. clippy wants the types to be explicitly stated here and
not inferred, to avoid potential undefined behaviour if an unexpected
type is inferred. however, the types that would be inferred here are
so complex, that the code would become illegible anyway, so ignore
this lint for now.
[1]:
https://rust-lang.github.io/rust-clippy/master/index.html#missing_transmute_annotations
Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
while usually this would improve ergonomics, in this case it isn't
clear whether all uses of `FromStr` would be considered valid here.
renaming the function would also make the type more confusing to use
as `from_str_with_default` also exists, so keep this for consistency.
this ignores a clippy lint [1].
[1]:
https://rust-lang.github.io/rust-clippy/master/index.html#should_implement_trait
Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
this fixes a clippy lint that complains about map invocations followed
by any invocations that are just checking for identity as this can be
replaced by just the any invocation alone [1].
[1]:
https://rust-lang.github.io/rust-clippy/master/index.html#map_all_any_identity
Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
While *technically* breaking as it changes the method signature for
the `create_ticket` call to use a struct for its parameters, this is
only (supposed to be) used via its `CREATE_TICKET_API_METHOD` handler
to be passed to a router. Direct use of this does not make sense.
Signed-off-by: Wolfgang Bumiller <w.bumiller@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>
previously the name in which the ticket was send was derived by the
product abbreviation in the ticket itself. the assumption was that
authentication cookies would always have a name like this:
`<PRODUCT_ABBREVIATION>AuthCookie`.
this commit adds helpers that allow specifying the cookie's name by
users of this crate.
Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
tickets that end in `::ticketinfo` are not properly signed and just
include information such as the timestamp when the ticket was created.
Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
this allows client to be aware that the ticket they manage is
informational only and that the real ticket should have been set via
a HttpOnly cookie.
Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
depending on the context a client may or may not have access to
HttpOnly cookies. this change allows them to pass such values to
`proxmox-login` to take them into account when parsing login
responses.
Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
in certain context (for example, the browser), no password needs to be
provided when using HttpOnly cookies as they are handle by said
context. so make renewing ticket with password optional and add a new
helper function that does not require a password.
Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
tickets created through the new HttpOnly ticket endpoint won't return
a ticket in the password field. so this field will be left empty.
hence make it optional.
the endpoint does return a ticket_info parameter, though, that
includes the information when a ticket needs to be refreshed. so add
a new optional field for that too.
Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
adds a new endpoint that is useful when dealing with HttpOnly cookies
that cannot be removed by client-side javascript (and by extension
wasm) code. the logout handle simply removes the cookie that is used
for storing the current ticket. this works the same way as it does in
the front-end: by setting an expired cookie with the same name.
as cookies are now prefixed with `__Host-` by default, the cookie here
also needs to be `Secure` and have the same `Path` to not be rejected
by the browser before it can remove the old cookie.
Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
this adds a new endpoint for requesting tickets. instead of returning
the ticket in the responses body, the ticket is set as a HttpOnly
cookie. this has a couple of advantages:
- the cookie cannot be stolen if an attacker downgrades the connection
to http and injects malicious javascript (`HttpOnly`)
- we don't need to rely on the client to make sure that the cookie is
only send in the appropriate context and only over https
connections (`Secure`, `SameSite`).
- the cookie cannot be overwritten by other subdomains, insecure
connections etc. (the default is to prefix them with `__Host-`)
this follows the best practice guide for secure cookies from MDN
[1]. we also set the cookies to expire when the ticket would so that
the browser removes the cookie once the ticket isn't valid anymore.
the endpoint still returns a ticket that only contains the
informational portions of the ticket but not a valid signature. this
is helpful to let clients know when to refresh the ticket by querying
this endpoint again. it still protects the cookie, though, as it
isn't a valid ticket by itself.
[1]: https://developer.mozilla.org/en-US/docs/Web/Security/Practical_implementation_guides/Cookies
Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
this makes sure that newly generated cookies that are prefixed with,
for example, `__Host-`, for security purposes, are correctly picked
up on. otherwise, the new cookies would not be able to yield proper
authentication.
currently this still falls back to insecure non-prefixed cookies. we
should deprecate them in the long-term and remove this fallback.
Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
this adds the function `prefixed_auth_cookie_name` to the
`AuthContext` trait. said function can be used by users of this crate
to modify the expected prefix of the auth cookie. most products
should be able to use the default of `__Host-` though, so this also
adds a default implementation.
Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
this allows us to write api handlers that have access to a request's
headers and to create a low level response while being able to also
specify the parameter in the request's body. this is useful for
endpoints that should not use url parameters, but still need to
access/set specific headers.
previously, `AsyncHttp` did not allow for parameters that were marked
as non-optional to be passed in the body of a request.
as a side-effect, the body is parsed by the rest server to check for
parameters and consumed. so it cannot be passed on by the handler.
Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
this function does not require ownership of the parts parameter, so we
can simply borrow it. this way we can pass the parameter on to a
handler that consumes them even when using `get_request_parameter`
Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
(it's on the wrong function, and also it's wrong - std's str
comparison forwards to the byte comparison anyway since this is fine
for utf-8 if we're not doing anything natural-language-aware...)
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
This verifies *at compile time* that the properties and variants of
ObjectSchemas and OneOfSchemas are sorted.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
