openbmc/bmcweb/DEVELOPING.md

1 # OpenBMC Webserver Development
7 As OpenBMC is intended to be deployed on an embedded system, care should be
11 - Binaries and static files should take up < 1MB of filesystem size
12 - Memory usage should remain below 10MB at all times
13 - Application startup time should be less than 1 second on target hardware
29 - All buffer boundaries must be checked before indexing or using values
30 - All pointers and iterators must be checked for null before dereferencing
31 - All input from outside the application is considered untrusted, and should be
34 - All error statuses are checked and accounted for in control flow.
35 - Where applicable, noexcept methods should be preferred to methods that use
37 - Explicitly bounded types should be preferred over implicitly bounded types
39 - no use of
40 …[Banned functions](https://github.com/intel/safestringlib/wiki/SDL-List-of-Banned-Functions "Banne…
47 - 200 OK - Request was properly handled
48 - 201 Created - Resource was created
49 - 401 Unauthorized - Request didn't posses the necessary authentication
50 - 403 Forbidden - Request was authenticated, but did not have the necessary
52 - 404 Not found - The url was not found
53 - 500 Internal error - Something has broken within the OpenBMC web server, and
57 possibility for subtle security bugs.
61 Given that the most common target of OpenBMC is an ARM11 processor, care needs
64 - Minimizing the number of files read from disk at startup. Unless a feature is
69 - Avoid excessive memory usage and mallocs at startup.
73 - At this point in time, the webserver sets a number of security flags in
77 - Exceptions are currently enabled for webserver builds, but their use is
83 - Run time type information is disabled
84 - Link time optimization is enabled
90 - Basic authentication
91 - Cookie authentication
92 - Token authentication
96 authentication scheme that is in line with the rest of OpenBMC, and allows users
99 ### Web security
101 The OpenBMC webserver shall follow the latest OWASP recommendations for
102 authentication, session management, and security.
106 The performance priorities for the OpenBMC webserver are (in order):
118 In general, the OpenBMC webserver is built using the data driven design.
124 ### webui-vue
126 The webserver should be capable of hosting webui-vue, and implementing the
134 [Redfish support document](https://github.com/openbmc/bmcweb/blob/master/Redfish.md)
136 [OEM SCHEMAS](https://github.com/openbmc/bmcweb/blob/master/OEM_SCHEMAS.md).
142 any openbmc development.
143 [Common Errors](https://github.com/openbmc/bmcweb/blob/master/COMMON_ERRORS.md).
148 [link](https://github.com/openbmc/docs/blob/master/CONTRIBUTING.md#formatting-commit-messages)
152 - Why are the changes useful? Given that bmcweb is a user-facing daemon, commits
156 - What changes would a user expect to see? This includes new parameters, new
160 - Are there compatibility concerns? Is this change backward compatible for
168 > Don't make your users mad -
169 > [Greg K-H](https://git.sr.ht/~gregkh/presentation-application_summit/tree/main/keep_users_happy.p…
176 OpenBMC version without issue, and resolves a significant bottleneck in getting
177 security patches deployed to users. Any change that's visible to a user is
182 - New items added to a collection
183 - Changes in UID for hypermedia resources (In line with Redfish spec)
184 - New properties added to a resource
185 - New versions of a given schema
192 Security: There may be cases where maintainers make explicit breaking changes in
193 the best interest of security; In these rare cases, the maintainers and
195 possible, but as with all security, impact will need to be weighed against the
196 security impact of not making changes, and judgment calls will be made, with
199 ### clang-tidy
201 clang-tidy is a tool that can be used to identify coding style violations, bad
203 .clang-tidy file in the root of bmcweb, and are expected to be passing.
204 [openbmc-build-scripts](https://github.com/openbmc/openbmc-build-scripts/blob/master/run-unit-test-…
205 implements clang-tidy checks and is the recommended way to run these checks
211 - debug
212 - info
213 - warning
214 - error
215 - critical
219 - critical: Something went badly wrong, and we're no longer able to serve
223 - error: Something went wrong, and we weren't able to give the expected
227 - warning: A condition occurred that is outside the expected flows, but isn't
230 - info: Information for the golden path debugging.
231 - debug: Information that's overly verbose such that it shouldn't be printed in
240 -Dlogging='debug'
247 EXTRA_OEMESON:pn-bmcweb:append = "-Dbmcweb-logging='debug'"