Gitiles
Code Review Sign In
gerrit.openbmc.org / openbmc / bmcweb / 471a5eb867c6a3e625bc5745edac8e56ad2e549c
commit471a5eb867c6a3e625bc5745edac8e56ad2e549c[log] [tgz]
authorAppaRao Puli <apparao.puli@linux.intel.com>Wed May 20 00:13:22 2020 +0530
committerAppaRao Puli <apparao.puli@linux.intel.com>Fri May 29 18:26:14 2020 +0000
treeeded03aaa8f070b4d73d35da210418b0e554dd11
parent2056b6d167a3ecb3c1615d906624a91259dc6c1f [diff]
Update json helper function - readJson

The json helper functions are currently coupled
with response(crow::response) and limiting it to
use only while sending response. There are some
use cases where we don't send crow::response
instead we extract json data from files and load
configuration.

Decoupled the business logic for validating json
key existence, json value type checking and range
validation with top level use cases. So this json
helper functions can be used for validating json
and extracting value from json object during
init cases also(Ex: Used in EventService config
initialization)

Added new API in helper function which checks
key existence, value is of desired Type and
value is in acceptable range and assign value
in output parameter.

Tested:
Verified post and patch methods with different
kinds of value types( int, bool, string, vector
array, json etc..) and it works.

Change-Id: I21a6f9a12aef09f6ca79a02bc01d96efeeb3a20a
Signed-off-by: AppaRao Puli <apparao.puli@linux.intel.com>
1 file changed
tree: eded03aaa8f070b4d73d35da210418b0e554dd11
  1. cmake/
  2. http/
  3. include/
  4. redfish-core/
  5. scripts/
  6. src/
  7. static/
  8. .clang-format
  9. .gitignore
  10. bmcweb.service.in
  11. bmcweb.socket
  12. build_x86.sh
  13. cmake-format.json
  14. CMakeLists.txt
  15. CMakeLists.txt.in
  16. config.h.in
  17. DEVELOPING.md
  18. JenkinsFile
  19. LICENCE
  20. MAINTAINERS
  21. pam-webserver
  22. README.md
  23. Redfish.md
README.md

OpenBMC webserver

This component attempts to be a "do everything" embedded webserver for openbmc.

Capabilities

At this time, the webserver implements a few interfaces:

  • Authentication middleware that supports cookie and token based authentication, as well as CSRF prevention backed by linux PAM authentication credentials.
  • An (incomplete) attempt at replicating phosphor-dbus-rest interfaces in C++. Right now, a few of the endpoint definitions work as expected, but there is still a lot of work to be done. The portions of the interface that are functional are designed to work correctly for phosphor-webui, but may not yet be complete.
  • Replication of the rest-dbus backend interfaces to allow bmc debug to logged in users.
  • An initial attempt at a read-only redfish interface. Currently the redfish interface targets ServiceRoot, SessionService, AccountService, Roles, and ManagersService. Some functionality here has been shimmed to make development possible. For example, there exists only a single user role.
  • SSL key generation at runtime. See the configuration section for details.
  • Static file hosting. Currently, static files are hosted from the fixed location at /usr/share/www. This is intended to allow loose coupling with yocto projects, and allow overriding static files at build time.
  • Dbus-monitor over websocket. A generic endpoint that allows UIs to open a websocket and register for notification of events to avoid polling in single page applications. (this interface may be modified in the future due to security concerns.

Configuration

BMCWeb is configured by setting -D flags that correspond to options in bmcweb/CMakeLists.txt and then compiling. For example, cmake -DBMCWEB_ENABLE_KVM=NO ... followed by make. The option names become C++ preprocessor symbols that control which code is compiled into the program.

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

  • is issued by C=US, O=OpenBMC, CN=testhost,
  • is valid for 10 years,
  • has a random serial number, and
  • is signed using the SHA-256 algorithm.