| commit | 1d3c14aa49a6c814a0e106540d82aeb4d1473d25 | [log] [tgz] |
|---|---|---|
| author | Ed Tanous <edtanous@google.com> | Wed Sep 22 18:54:40 2021 -0700 |
| committer | Ed Tanous <ed@tanous.net> | Fri Oct 08 23:17:04 2021 +0000 |
| tree | 3e95facf6a52ee064776f54d6af1257ceb82aabd | |
| parent | 259df359c457c9972feb24170d41dfdcbb5eef0a [diff] |
Split up authenticate This commit attempts to split up the authenticate method to make it easier to audit, and to simplify some duplicated URL parsing code. First, some history: authenticate used to be token authentication middleware, then it got promoted into http connection, because of security concerns (we needed to effectively rate limit unauthenticated users). Then we got rid of middlewares entirely, then we rearranged the ownership of request such that it owns all its data and inits later in the cycle. This has caused a mess, so lets try to clean it up and make the connection class simpler. This commit specifically breaks up authenticate into two parts, the first, which is the same as the old authenticate, is responsible for actually authenticating the user, and no longer carries the authorization credentials and allowlist with it. The allowlist, as well as actually returning 401 is now moved into handle, where it makes more sense, as the request is complete, and we can immediately invoke the action, instead of having to set the isCompleted flag and wait until later. Because of this again, now the only calls to completeRequest are called from handle(), which means we can remove the extra "if (req.completed)" check we formerly had to do for authenticate, continuing to make authenticate less of a special case. The only possible negative to this patch, is now any allowlisted endpoints still have to call through the authenticate code, whereas previously they could take a fast path. This code runs all requests against authenticate, regardless of their allowlist status. In theory, this makes this slower, in practice, It seems to be an unmeasurable impact. Tested: curl --insecure "https://192.168.7.2/redfish/v1" Returns the redfish v1 resource curl --insecure "https://192.168.7.2/redfish/v1/Systems" Returns 401 unauthorized curl --insecure --user root:0penBmc "https://192.168.7.2/redfish/v1/Systems" returns the SystemsCollection Signed-off-by: Ed Tanous <edtanous@google.com> Change-Id: Ic9c686b8da7bb6c03b9c113a6493f0e071b5bc77
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.