| commit | 2d6cb56b6b47c3fbb0d234ade5c1208edb69ef1f | [log] [tgz] |
|---|---|---|
| author | Ed Tanous <edtanous@google.com> | Thu Jul 07 20:44:54 2022 -0700 |
| committer | Ed Tanous <ed@tanous.net> | Tue Dec 06 22:17:31 2022 +0000 |
| tree | 62f0c97e3eb291d6b0bf943fa6868bb8624ae056 | |
| parent | c0bdf22334f859d1d2a522d3841160f579a3cbab [diff] |
Implement If-Match header in Http layer If-Match is a header in the HTTP specification[1] designed for handling atomic operations within a given HTTP tree. It allows a mechanism for an implementation to explicitly declare "only take this action if the resource has not been changed". While most things within the Redfish tree don't require this level of interlocking, it continues to round out our redfish support for the specific use cases that might require it. Redfish specification 6.5 states: If a service supports the return of the ETag header on a resource, the service may respond with HTTP 428 status code if the If-Match or If-None-Match header is missing from the PUT or PATCH request for the same resource, as specified in RFC6585 This commit implements that behavior for all handlers to follow the following flow. If If-Match is present Repeat the same request as a GET Compare the ETag produced by the GET, to the one provided by If-Match If they don't match, return 428 if they do match, re-run the query. [1] https://www.rfc-editor.org/rfc/rfc2616#section-14.24 As a consequence, this requires declaring copy and move constructors onto the Request object, so the request object can have its lifetime extended through a request, which is very uncommon. Tested: Tests run on /redfish/v1/AccountService/Accounts/root PATCH with correct If-Match returns 200 success PATCH with an incorrect If-Match returns 419 precondition required GET returns the resource as expected Redfish service validator passes Redfish protocol validator passes! ! ! ! ! Signed-off-by: Ed Tanous <edtanous@google.com> Change-Id: I530ab255259c32fe4402eb8e5104bd091925c77b
This component attempts to be a "do everything" embedded webserver for OpenBMC.
The webserver implements a few distinct interfaces:
bmcweb at a protocol level supports http and https. TLS is supported through OpenSSL.
Bmcweb supports multiple authentication protocols:
Each of these types of authentication is able to be enabled or disabled both via runtime policy changes (through the relevant Redfish APIs) or via configure time options. All authentication mechanisms supporting username/password are routed to libpam, to allow for customization in authentication implementations.
All authorization in bmcweb is determined at routing time, and per route, and conform to the Redfish PrivilegeRegistry.
*Note: Non-Redfish functions are mapped to the closest equivalent Redfish privilege level.
bmcweb is configured per the meson build files. Available options are documented in meson_options.txt
meson builddir ninja -C builddir
If any of the dependencies are not found on the host system during configuration, meson will automatically download them via its wrap dependencies mentioned in bmcweb/subprojects.
bmcweb by default is compiled with runtime logging disabled, as a performance consideration. To enable it in a standalone build, add the
-Dlogging='enabled'
option to your configure flags. If building within Yocto, add the following to your local.conf.
EXTRA_OEMESON:pn-bmcweb:append = "-Dbmcweb-logging='enabled'"
bmcweb relies on some on-system data for storage of persistent data that is internal to the process. Details on the exact data stored and when it is read/written can seen from the persistent_data namespace.
When SSL support is enabled and a usable certificate is not found, bmcweb will generate a self-signed a certificate before launching the server. Please see the bmcweb source code for details on the parameters this certificate is built with.