| commit | c127a0f4d49fd2152e8c25615aedc53aa8ded1d5 | [log] [tgz] |
|---|---|---|
| author | Ed Tanous <edtanous@google.com> | Wed May 11 15:23:59 2022 -0700 |
| committer | Ed Tanous <ed@tanous.net> | Mon Jun 06 18:19:14 2022 +0000 |
| tree | 6c983374ef2a778b6dbb0c8c90db219e0a029d6d | |
| parent | 92903bd47b8d2e2b2e777d1ba61871a3b54fefd4 [diff] |
Fix www-authenticate behavior bmcweb is in a weird position where, on the one hand, we would like to support Redfish to the specification, while also supporting a secure webui. For better or worse, the webui can't currently use non-cookie auth because of the impacts to things outside of Redfish like websockets. This has lead to some odd code in bmcweb that tries to "detect" whether the browser is present, so we don't accidentally pop up the basic auth window if a user happens to get logged out on an xhr request. Basic auth in a browser actually causes CSRF vulnerabilities, as the browser caches the credentials, so we don't want to make that auth method available at all. Previously, this detection was based on the presence of the user-agent header, but in the years since this code was originally written, a majority of implementations have moved to sending a user-agent by default, which makes this check pretty much useless for its purpose. To work around that, this patchset relies on the X-Requested-With header, to determine if a json payload request was done by xhr. In theory, all browsers will set this header when doing xhr requests, so this should provide a "more correct" solution to this issue. Background: https://en.wikipedia.org/wiki/List_of_HTTP_header_fields "X-Requested-With Mainly used to identify Ajax requests (most JavaScript frameworks send this field with value of XMLHttpRequest)" Tested: curl -vvvv --insecure https://192.168.7.2/redfish/v1/SessionService/Sessions Now returns a WWW-Authenticate header Redfish-protocol-validator now passes 7 more tests from the RESP_HEADERS_WWW_AUTHENTICATE category. Launched webui-vue and logged in. Responses in network tab appear to work, and data populates the page as expected. Used curl to delete redfish session from store with DELETE /redfish/v1/SessionService/Sessions/<SessionId> Then clicked an element on the webui, page forwarded to login page as expected. Opened https://localhost:8000/redfish/v1/CertificateService in a browser, and observed that page forwarded to the login page as it should. Signed-off-by: Ed Tanous <edtanous@google.com> Change-Id: I60345caa41e520c23fe57792bf2e8c16ef144a7a
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 -C builddir test ninja -C builddir coverage
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.