commit | cf099faa88e6fe8679d8d2c209b0471bfcc6e891 | [log] [tgz] |
---|---|---|
author | Ed Tanous <edtanous@google.com> | Wed Aug 25 12:37:31 2021 -0700 |
committer | Ed Tanous <ed@tanous.net> | Thu Sep 09 02:22:53 2021 +0000 |
tree | 9e4619598485a172da0ba833a957f4e292f2301d | |
parent | 59b98b2222fddbea3d6f678d9e94006521f0c381 [diff] |
Remove unused variables in connection class Both of these variables are leftover from when middlewares existed in this codebase, and are essentially unused. The only use is to buffer cleanupTempSession, which in practice, doesn't require the variable, and can be run in all cases. Because this code is "cleaning up" the basic auth session that got created when the request started, in theory, if the request failed, it's possible we didn't create a session, but that can happen through the golden path too, if we access an unprotected resource, or access with non basic auth, so there's no reason to hide this behind the "did the middlewares fail" check. This got stuck under the check because of the way the middlewares used to be ordered, to keep "identical" code paths. Tested: curl -vvvv --insecure --auth root:0penBmc"https://192.168.7.2:443/redfish/v1/Systems" Succeeded with and without the --auth flag. This tests basic auth, which is the only thing that could've been potentially changed as part of this commit. Signed-off-by: Ed Tanous <edtanous@google.com> Change-Id: I8d2500fd2abaab3b23abed51a9a9f55e8d171b76
This component attempts to be a "do everything" embedded webserver for openbmc.
At this time, the webserver implements a few interfaces:
BMCWeb is configured by setting -D
flags that correspond to options in bmcweb/meson_options.txt
and then compiling. For example, meson <builddir> -Dkvm=disabled ...
followed by ninja
in build directory. The option names become C++ preprocessor symbols that control which code is compiled into the program.
meson builddir ninja -C builddir
meson builddir -Dbuildtype=minsize -Db_lto=true -Dtests=disabled ninja -C buildir
If any of the dependencies are not found on the host system during configuration, meson automatically gets them via its wrap dependencies mentioned in bmcweb/subprojects
.
meson builddir -Dwrap_mode=nofallback ninja -C builddir
meson builddir -Dbuildtype=debug ninja -C builddir
meson builddir -Db_coverage=true -Dtests=enabled ninja coverage -C builddir test
When BMCWeb starts running, it reads persistent configuration data (such as UUID and session data) from a local file. If this is not usable, it generates a new configuration.
When BMCWeb SSL support is enabled and a usable certificate is not found, it will generate a self-sign a certificate before launching the server. The keys are generated by the secp384r1
algorithm. The certificate
C=US, O=OpenBMC, CN=testhost
,SHA-256
algorithm.