Request for comments: C++ embedded webserver

[Michael.E.Brown at dell.com]

I started reviewing some of the code, and I have quite a few thoughts, let's see if I can convey them without writing a book. The main aspect I'm looking at is the redfish interface, but many of these apply equally well to the REST and redfish parts. Here are my initial thoughts when looking at this proposal.

1) extensibility: I see openbmc as a base that many people will want to build upon. To enable that, we need to be able to have easy ways to extend or override the things in the base.

-          Compile time extensions vs runtime loadable - open question

-          Need to add OEM extensions to individual URLs

-          Need to override specific properties in an individual URL

-          Need to be able to add entire new URI trees

-          Need to extend existing trees with links/references to new trees

-          Need to dynamically generate the metadata URIs

My commentary while reviewing this code is that I don't immediately see obvious ways of doing any of these extensions that don't effectively fork the entire codebase and make future maintenance much more difficult.

2) (redfish) Easier ways of generating JSON and mapping JSON properties to backend data: The initial code to generate JSON I see here is quite simple, but one aspect worries me. It appears that you have a nice and simple way to create the output JSON data structure, but right now most everything is hard coded. Once you start filling in the data "for real", we will need to write an ever-growing pile of code to translate from DBUS calls to get the data and poke the data into the correct spot in the JSON output.  In my mind, DBUS is introspectable and JSON is introspectable. It seems like it would be a big win to create a small, generic JSON engine that holds the data and then reads metadata about which calls to make to update the data.

3) performance: It looks like you currently make backend calls to satisfy requests for data. This means that more frontend calls will result in higher load on the backend. This means that it would be possible for frontend load to impact things like power/thermal reaction times without some limits on the frontend webserver. However, the DBUS architecture has a signal based system for generating events that we could leverage. The webserver could keep an internal copy of all of its JSON output and subscribe to DBUS signals/events to update that internal cache. This way, external web requests do not automatically translate every time into internal DBUS calls. The webserver could easily satisfy most web requests using data it already has on hand. This would result in much higher performance

4) security: the redfish standard has extension points to enable uploading new permission mappings or dynamically create roles and permissions. It's not clear to me how we would satisfy these dynamic security requirements

Token infrastructure: I haven't looked at this code yet. In general, though, I really like having token-based security middleware so that we can provide extensions to support OAuth 2.0 and OpenID Connect support. The main idea here is that we need a way to delegate security decisions to a trusted third party. If we are using standard JWT tokens compatible with OIDC for identity, this makes the transition much easier.

--
Michael

From: openbmc [mailto:openbmc-bounces+michael.e.brown=dell.com at lists.ozlabs.org] On Behalf Of Tanous, Ed
Sent: Monday, December 18, 2017 10:08 PM
To: OpenBMC Maillist <openbmc at lists.ozlabs.org>
Subject: Request for comments: C++ embedded webserver

I'm looking for comments on a code review that's been outstanding.  One of the large pushes we've made is to attempt to make the web server more efficient, and add capabilities that comprehend long term needs of OpenBmc.  One key that wasn't made clear in the commit message is that it includes the basic redfish implementation that (we hope) should be extensible to the full redfish specification in the short term future.

https://gerrit.openbmc-project.xyz/#/c/7786/

We would very much appreciate comments to see if we can move this forward.

The following description is pulled from the readme.

# 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.  If an RSA key and cert pair are not available to the server at runtime, keys are generated using the openssl routines, and written to disk.
+ 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.)


Thanks,

-Ed

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20171220/d24f8785/attachment.html>