| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Error message to be thrown when StrictAccountTypes is true and the
specified value(s) for AccountTypes or OEMAccountTypes was not accepted.
Testing:
strictAccountTypes() error message was tested while testing redfish
PATCH API for patching AccountTypes.
Signed-off-by: Shantappa Teekappanavar <shantappa.teekappanavar@ibm.com>
Change-Id: I13abcd142ddfb04a2a187c9373fa996ecfe987a1
|
|
The existing code doesn't propogate errors of subqueries correctly.
This commit corrects the behavior, so that the final response gets all
error message of subqueries and the "highest priority" HTTP code.
DMTF doesn't specify how expand queries handle error codes, since using
subqueries is an implementation choice that we made in this project.
What we did here follows existing behavior of this project, and follows
the error message section of the Redfish spec;
[1] https://redfish.dmtf.org/schemas/DSP0266_1.15.1.html#error-responses
As for now, this commit uses the worst HTTP code among all the error
code. See query_param.hpp, function |propogateErrorCode| for detailed
order of the errror codes.
Tested:
1. this is difficult to test, but I hijacked the code so it returns
errors in TaskServices, then I verified that "/redfish/v1?$expand=."
correctly returns 500 and the gets the error message set.
2. unit test so that when there are multiple errors, the final response
gets a generate error message.
Signed-off-by: Nan Zhou <nanzhoumails@gmail.com>
Change-Id: I0c1ebdd9015f389801db9150d687027485f1203c
|
|
There's a few last places (outside of tests) where we still use
nlohmann brace initialization. Per the transforms we've been doing,
move these to constructing the objects explicitly, using operator[],
nlohmann::object_t and nlohmann::array_t. Theses were found by manual
inspection grepping for all uses of nlohmann::json.
This is done to reduce binary size and reduce the number of intermediate
objects being constructed. This commit saves a trivial amount of size
(~4KB, Half a percent of total) and in addition but makes our
construction consistent.
Tested:
Redfish service validator passes.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I7478479a9fdc41b254eef325002d413c1fb411a0
|
|
Redfish has specific error messages for OperationNotSupported in the
Base registry. This commit allows bmcweb to return both the correct
return code (405) and the correct error message, while not effecting the
rest of the tree.
We didn't have the equivalent call in error_messages, so this adds the
required call.
Tested:
GET /redfish/v1 returns ServiceRoot
GET /redfish/v1/foo Returns 404
PATCH /redfish/v1 returns 405 OperationNotSupported
POST /redfish/v1/Chassis returns 405 OperationNotSupported
DELETE /redfish/v1/Chassis returns 405 ResourceCannotBeDeleted
POST /redfish/v1/foo/bar Returns 404
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I6f980af7307af602344b65a12a2b7589cc9ec959
Signed-off-by: Carson Labrado <clabrado@google.com>
|
|
I found that error_messages.cpp missed headers when adding
insufficientResource errors. This commit is like the other incremental
iwyu effort. Now error message library is fixed.
Tetsted: compiles.
Signed-off-by: Nan Zhou <nanzhoumails@gmail.com>
Change-Id: Ia5f4716d21a98cad56ec2ae0b842a40ed825cb17
|
|
In the spec, when a response is too large, we need a error messsage to
represent such error. The corresponding error is 507 Insufficient
Storage, which is already in the base registry.
This commit adds that utility to error messages library.
Reference: redfish spec Section 7.3.2
```
If a service cannot return the payload due to its size, it shall return
the HTTP 507 Insufficient Storage status code.
```
Tested: code compies.
Signed-off-by: Nan Zhou <nanzhoumails@gmail.com>
Change-Id: I1fe840f015b3d67fa2092d1d3a1f8c3fcbc2c438
|
|
Very similar to how the base registry was optimized for binary size,
optimize the resource event registry, by making the getLogFromRegistry a
common method for both registries.
Tested: Only usage of these calls appears to be in management console.
The code and pattern we're using here is well unit tested, and seems
reasonable that we could rely on the compile time checks, but if not, I
could use some help testing this.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I9cc442966df2ed301b14547727a5eb727c0c3a29
|
|
There are two overloads of addHeader, one that takes a string, and one
that takes a boost enum. For most common headers, boost contains a
string table with all of those entries anyway, so there's no point in
duplicating the strings, and ensures that we don't make trivial
mistakes, like capitalization or - versus underscore that aren't caught
at compile time.
Tested:
This saves a trivial amount (572 bytes) of compressed binary size.
curl --insecure -vvv --user root:0penBmc https://192.168.7.2/redfish/v1
returns < Content-Type: application/json
curl --insecure -vvv -H "Accept: text/html" --user root:0penBmc https://192.168.7.2/redfish/v1
Returns
< Content-Type: text/html;charset=UTF-8
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I34c198b4f9e219247fcfe719f9b3616d35aea3dc
|
|
This normally wouldn't be so big of a deal, but the redfish-protocol
validator tests this case in the REQ_PATCH_BAD_PROP test.
From the specification:
'''
If all properties in the update request are read-only, unknown, or
unsupported, but the resource can be updated, the service shall return
the HTTP 400 Bad Request status code and an error response with messages
that show the non-updatable properties.
'''
We wrote our code almost right for handling this case, but we put the
response into the per-property responses instead of the error responses.
In terms of backward compatibility, technically this is changing the
behavior, but considering that it's behavior in an error case, most
implementations only look at response code, and this is moving to be
compliant with the specification, it doesn't seem like there would be
any reason to provide both the old message and the new one, and this has
a low to zero likelihood of any actual impact. To hit this condition,
clients would have to be ignoring the error code response AND using a
property that's unknown to the BMC. Clients that make both mistakes
seems unlikely.
Tested:
Code now passes the REQ_PATCH_BAD_PROP test. 10 failing test cases down
to 8.
'''
curl -vvvv --insecure --user root:0penBmc https://192.168.7.2/redfish/v1/AccountService/ -X PATCH -d '{"foo": "bar"}'
'''
Returns an object with an "error" key in it.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I8a19ed2bcfc91765b63d4544877332038e171c02
|
|
The PropertyValueOutOfRange error indicates that a property was given
the correct value type but the value of that property is outside the
supported range.
Tested:
Build pass.
Change-Id: I78d5e3142b41d6739e6b0ff4699e1c731c5981d7
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@intel.com>
|
|
This file is empty and is not referenced anywhere. So just delete it.
Tested: code compiles.
Signed-off-by: Nan Zhou <nanzhoumails@gmail.com>
Change-Id: Ib2c743cf6ff06b8a68b7a887da5eee28a6d481f0
|
|
Redfish base registry for operation failed says:
"Indicates that one of the internal operations necessary to complete the
request failed. Examples of this are when an internal service provider
is unable to complete the request, such as in aggregation or RDE."
In terms of return codes, this translates to 502, Bad Gateway, given
that we're talking about proxy behavior here.
There is currently one usage of messages::operationFailed, which
arguably should've used internalErrror, and will be fixed in the next
patchset.
Tested: Code compiles. No (correct) users.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: Iff20e04d4f297b9f6595039f76321d0927f86c4d
|
|
Any query param errors from the base registry being sent imply that the
user-provided parameters were bad, which should return bad request, not
forbidden. This is in line with the spec.
Luckily, the only usage of these parameters as of now is from within the
query params support model, so changing it shouldn't cause any backward
compatibility issues, and because these are meant for "bad request" type
messages, it's unlikely it would even be able to effect clients.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I13a4601d1236d9eaac6bbf5fb25e0f1b28c04a21
|
|
Brace initialization of json objects, while quite interesting from an
academic sense, are very difficult for people to grok, and lead to
inconsistencies. This patchset aims to remove a majority of them in
lieu of operator[]. Interestingly, this saves about 1% of the binary
size of bmcweb.
This also has an added benefit that as a design pattern, we're never
constructing a new object, then moving it into place, we're always
adding to the existing object, which in the future _could_ make things
like OEM schemas or properties easier, as there's no case where we're
completely replacing the response object.
Tested:
Ran redfish service validator. No new failures.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: Iae409b0a40ddd3ae6112cb2d52c6f6ab388595fe
|
|
Section 7.3 of the Redfish specification lays out a feature called
"expand" that allows users to expand portions of the Redfish tree
automatically on the server side. This commit implements them to the
specification.
To accomplish this, a new class, MultiAsyncResp is created, that allows
RAII objects to handle lifetime properly. When an expand query is
generated, a MultiAsyncResp object is instantiated, which allows "new"
requests to attach themselves to the multi object, and keep the request
alive until they all complete. This also allows requests to be created,
while requests are in flight, which is required for queries above
depth=1.
Negatives:
Similar to the previous $only commit, this requires that all nodes
redfish nodes now capture App by reference. This is common, but does
interfere with some of our other patterns, and attempts to improve the
syntactic sugar for this proved unworkable.
This commit only adds the above to service root and Computer systems, in
hopes that we find a better syntax before this merges.
Left to future patches in series:
Merging the error json structures in responses.
The Redfish spec isn't very clear on how errors propagate for expanded
queries, and in a conforming we shouldn't ever hit them, but
nonetheless, I suspect the behavior we have is sub-optimal (attaching an
error node to every place in the tree that had an issue) and we should
attempt to do better in the future.
Tested (on previous patch):
curl --insecure --user root:0penBmc https://localhost:18080/redfish/v1\?\$expand\=.\(\$levels\=255\)
Returns the full tree
Setting $levels=1 query returns only a depth of 1 tree being returned.
Unit tests passing
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I874aabfaa9df5dbf832a80ec62ae65369284791d
|
|
- Added the PropertyValueExternalConflict message registry that
might used to send when the request is failed due to some other
resource state or configuration.
Signed-off-by: Ramesh Iyyar <rameshi1@in.ibm.com>
Change-Id: Ibdb8c21e285079dbaea54b99f207f45892b24ea9
|
|
- Added the PropertyValueResourceConflict message registry that
might used to send when the request is failed due to some other
resource state or configuration.
Signed-off-by: Ramesh Iyyar <rameshi1@in.ibm.com>
Change-Id: I2c03aee88442f6abe55f2a9f574211b8214aa30c
|
|
There are a couple places we missed inline/static on our headers, and a
couple unused message entry callbacks for which their parameters were
incorrect (which clang caught). Fix all of them.
Tested: Code compiles on clang. No-op changes.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I12c9c04d3b773c4991c6cd92d0cfd42b348762d6
|
|
In the way we store the message registry, we store both Severity and
MessageSeverity. Severity as a field is deprecated, and in every case
in every registry both fields have the same value. We shouldn't
duplicate data in that way. This commit changes the parse_registries.py
script to stop producing the Severity field into the struct. The few
uses we have left are moved over to use MessageRegistry.
Tested:
Redfish service validator shows no errors on the
/redfish/v1/Registries tree. Other errors present that were there
previously and are unchanged.
This saves a trivial amount: about 1kB on our compressed binary size.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: Ibbaf533dc59eb08365d6ed309aba16b54bc40ca1
|
|
The message_registries namespace is overly wordy, and results in very
long defines. Doing this one minor change reduces the code by 50 lines.
This seems worthwhile.
Tested: Unit tests pass. Namespace change only.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: Ib1401580b3fa47596eb56cdc86e60eeeb1c2f952
|
|
using std::string_view on these lets us call them in more contexts, and
allows us to inline some previously more complex code. In general, for
APIs like this, std::string_view should be preferred as it gives more
flexibility in calling conventions.
Tested:
curl --insecure "https://localhost:18080/redfish/v1/AccountService/Roles/foobar" ✔
{
"error": {
"@Message.ExtendedInfo": [
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The requested resource of type Role named 'foobar' was not found.",
"MessageArgs": [
"Role",
"foobar"
],
"MessageId": "Base.1.11.0.ResourceNotFound",
"MessageSeverity": "Critical",
"Resolution": "Provide a valid resource identifier and resubmit the request."
}
],
"code": "Base.1.11.0.ResourceNotFound",
"message": "The requested resource of type Role named 'foobar' was not found."
}
}
This is the same response as previously.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I8ee17120c42d2a13677648c3395aa4f9ec2bd51a
|
|
Internally to bmcweb, we actually store two copies of every string in
the base privilege registry. As history played out, the
error_messages.cpp was created first, then when logging was added, we
needed more fine grained programatic lookups into the message
registries, so we invented the constexpr array. Previously, it was
thought that xz basically deduplicated the duplicated strings. While
this is true to some extent, it using the actual processing code seems
to be a win on binary size.
This is also a -500 line diff, so it's reducing the amount of code we
have at the same time.
Note, the "InvalidUpload" message is incorrect per the standard, which
this patchset sort of teases out, as it's the only one that can't be
updated. This patchset leaves it as-written.
Tested:
xz compressed bmcweb went from 1174632 bytes, down to 1157040 bytes, or
a 1.4% (17592 bytes) reduction in compressed binary size.
curl --insecure --user root:0penBmc https://192.168.7.2/redfish/v1/Chassis/foobar
{
"error": {
"@Message.ExtendedInfo": [
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The requested resource of type #Chassis.v1_16_0.Chassis named 'foobar' was not found.",
"MessageArgs": [
"#Chassis.v1_16_0.Chassis",
"foobar"
],
"MessageId": "Base.1.11.0.ResourceNotFound",
"MessageSeverity": "Critical",
"Resolution": "Provide a valid resource identifier and resubmit the request."
}
],
"code": "Base.1.11.0.ResourceNotFound",
"message": "The requested resource of type #Chassis.v1_16_0.Chassis named 'foobar' was not found."
}
}
Note, the MessageId property has changed its version from Base.1.8 to
Base.1.11. This is correct and matches the version of the registry we
use. Also, the second argument is now quoted, as the ResourceNotFound
schema requires.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: Ifd0bd71a26eebeba8ba89704a1eca425f0776aa8
|
|
There are a number of places where we use message registry messages
incorrectly. This patchset attempts to fix them, and invoke some type
safety when they're used such that they're more obvious to use.
Namely, it changes a number of the message registry methods to accept a
boost::urls::url_view for its argument instead of a const std::string&.
This forces the calling code to correctly encode a URL to use the
method, which should make it obvious that it's not for an ID, a property
name, or anything else. In the course of doing this, several places
were found to be using the first argument incorrectly.
Tested:
curl --insecure --user root:0penBmc https://192.168.7.2/redfish/v1/Chassis/foobar
Returns:
{
"error": {
"@Message.ExtendedInfo": [
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The requested resource of type #Chassis.v1_16_0.Chassis named foobar was not found.",
"MessageArgs": [
"#Chassis.v1_16_0.Chassis",
"foobar"
],
"MessageId": "Base.1.8.1.ResourceNotFound",
"MessageSeverity": "Critical",
"Resolution": "Provide a valid resource identifier and resubmit the request."
}
],
"code": "Base.1.8.1.ResourceNotFound",
"message": "The requested resource of type #Chassis.v1_16_0.Chassis named foobar was not found."
}
Identically to previously.
Also tested with IDs that contained % encoded characters, like
foobar%10, which gave the same result.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: Icbb3bce5d190a260610087c9ef35e7becc5a50c7
|
|
The redfish base registry does not include a definition of this
message, which generating type-safe models has teased out. Replace the
MutuallyExclusiveProperties message with two "PropertyValueConflict"
messages. This seems like the closest thing, but in lieu of the things
not being in the standard, this seems like the best compromise.
Tested:
curl --insecure -X POST --user root:0penBmc
https://192.168.7.2/redfish/v1/EventService/Subscriptions -d
'{"MessageIds":[""],"RegistryPrefixes":[""],"Destination":"","Protocol":""}'
Returns:
{
"error": {
"@Message.ExtendedInfo": [
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The property 'MessageIds' could not be written because its value would conflict with the value of the 'RegistryPrefixes' property.",
"MessageArgs": [
"MessageIds",
"RegistryPrefixes"
],
"MessageId": "Base.1.8.1.PropertyValueConflict",
"MessageSeverity": "Warning",
"Resolution": "No resolution is required."
}
],
"code": "Base.1.8.1.PropertyValueConflict",
"message": "The property 'MessageIds' could not be written because its value would conflict with the value of the 'RegistryPrefixes' property."
}
}
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I1eaf4d06b6f5b85909392c48970e3f353af3a41e
|
|
Per the coding standard, we should be capturing this by int, not const
int&.
Tested: There are no uses of stringValueTooLong(), so noop change to
binary.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: Idfcb05c962e0a0d489db263a6f845bb1789b5842
|
|
Do a partial update from the include what you use tool.
While ideally we'd be able to do this as part of CI, there's still quite
a bit of noise in the output that requires manual intervention.
Tested:
Code compiles
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: Iaaeb7a9199f64b5d6913c3abab4779b252768ed8
|
|
Using int64_t instead of int, to permit 64-bit indices.
This is to support ExternalStorer, a new project I am working on,
which uses a 64-bit sequence number for long-term robustness.
Change-Id: I00121933067030fd722f6b02c2d2dbd1854dff1c
Signed-off-by: Josh Lehan <krellan@google.com>
|
|
Internal error call sites are propagated through the code, and might be
triggered multiple times in the course of a request, which makes them
difficult to track the source of.
This commit changes the internalError() method to include a print of
which invocation within bmcweb triggered the error, using c++20s
std::source_location mechanism.
Note:
clang-13 still doesn't implement std::source_location, so this commit
pulls source_location.hpp from lg2 to be able to support all compilers.
Tested:
Loaded in qemu, and added an internalError() call into systems.hpp for
the /redfish/v1/Systems handler. Observed that
[CRITICAL "error_messages.cpp":234] Internal Error
../../../../../../workspace/sources/bmcweb/redfish-core/include/../lib/systems.hpp(2820:40)
`redfish::requestRoutesSystemsCollection(App&)::<lambda(const
crow::Request&, const std::shared_ptr<bmcweb::AsyncResp>&)>`:
Got printed to the bmcweb logs.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: Ic1b4240422445357bc87404de814ad14f86b9edf
|
|
Tested By:
Code compiles
The error message is as follows:
{
"error": {
"@Message.ExtendedInfo": [
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The operation failed because the service at /redfish/v1/Systems/system/LogServices/Dump/ is disabled and cannot accept requests.",
"MessageArgs": [
"/redfish/v1/Systems/system/LogServices/Dump/"
],
"MessageId": "Base.1.11.0.ServiceDisabled",
"MessageSeverity": "Warning",
"Resolution": "Enable the service and resubmit the request if the operation failed."
}
],
"code": "Base.1.11.0.ServiceDisabled",
"message": "he operation failed because the service at /redfish/v1/Systems/system/LogServices/Dump/ is disabled and cannot accept requests."
}
}
Signed-off-by: Asmitha Karunanithi <asmitk01@in.ibm.com>
Change-Id: I923892ecd785e3b6c071fa663fee14a2754d5ef1
|
|
- The Message argument in the BIOSPOSTCode Message Entry
uses short form wording for TS (Time Stamp) & without any time unit.
- As the Message argument is directly displayed on OpenBMC GUI
as it is, word "TS" would create customer confusion due to it
not being a well known acronym. Also a field like this that
captures a physical quantity(time) should have units.
- Redfish clients should not be parsing the message argument, so
changing this wording should not break them.
- Also, this commit changes ":" to ";" in the Message argument to
makes things look consistent.
- As we changed the content of Message in the Message Entry, we had to
bump up the minor version of the Message registry.
Tested By:
1. Redfish Validator Passed.
Signed-off-by: Manojkiran Eda <manojkiran.eda@gmail.com>
Change-Id: I17924c2dfdcf34563f8f8cd325011e13cb70e476
|
|
From the redfish specification:
Redfish Services shall process the OData-Version header in the
following table as defined by the HTTP 1.1 specification.
<Table omitted, but shows "yes" for service requirements>
Services shall reject requests that specify an unsupported OData
version.
This code implements compliance with those two statements.
Tested:
curl -vvvv --insecure --user root:0penBmc -H "OData-Version: 4.1" https://<ip>/redfish/v1
Returns 412 Precondition Failed
curl -vvvv --insecure --user root:0penBmc -H "OData-Version: 4.0" https://<ip>/redfish/v1
returns 200
curl -vvvv --insecure --user root:0penBmc https://<ip>/redfish/v1
returns 200
The equivalent Redfish-Protocol-Validator tests now pass
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I50350b913f17ae35588e2f0606c56164f00dc2a9
|
|
The odata.type of the message, included in the error response JSON
is changed to point to the latest one (Message.v1_1_1) as there was
conflict in the code, where it points to v1_0_0 schema and a property
- MessageSeverity has been used (introduced in v1_1_0)
Tested By:
{
"error": {
"@Message.ExtendedInfo": [
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The request failed due to an internal service error. The service is still operational.",
.
.
.
}
],
"code": "Base.1.4.0.InternalError",
"message": "The request failed due to an internal service error. The service is still operational."
}
}
Signed-off-by: Asmitha Karunanithi <asmitk01@in.ibm.com>
Change-Id: I57546adaffc2370c0314a2c2184799c387ec7272
|
|
cppcheck isn't smart enough to recognize these are c++ headers, not c
headers. Considering we're already inconsistent about our naming, it's
easier to just be consistent, and move the last few files to use .hpp
instead of .h.
Tested:
Code builds, no changes.
Signed-off-by: Ed Tanous <ed@tanous.net>
Change-Id: Ic348d695f8527fa4a0ded53f433e1558c319db40
|
|
https://github.com/openbmc/bmcweb/issues/150
Return code should be 503 Service Unavailable, not 403, unauthorized.
The user is authorized, but resources aren't available.
Tested:
Looking for help here.
Signed-off-by: Ed Tanous <ed@tanous.net>
Change-Id: I839df925d1d27411986cb01ffbd19a3ee8ffb1b2
|
|
The Base message registry has updated to 1.8.1. This updates our
error_messages files to match.
This changes from the deprecated 'Severity' to the new
'MessageSeverity' property.
It also adds a script to compare our error_messages.cpp messages
against the Base message registry and flag any differences.
Tested:
Ran the Redfish Validator and confirmed that this change does
not introduce any new failures.
Change-Id: I2e5101a5b4d0c0963569493451f99521e42b0f4d
Signed-off-by: Jason M. Bills <jason.m.bills@linux.intel.com>
|
|
Add MutualExclusiveProperties message registry entry
and error message.
As per redfish specification, "RegistryPrefixes" and
"MessageIds" are mutually exclusive. So add check for
same in EventService and return MutualExclusiveProperties
error message.
Tested:
- Create subscription failed with error(bad request)
when the request body contain both "RegistryPrefixes"
and "MessageIds".
Change-Id: I4c14f946977bce2ced8a7f96eb85855117fde9a8
Signed-off-by: AppaRao Puli <apparao.puli@linux.intel.com>
|
|
THis adds support for better error responses based on
the logs generated by phosphor-software-manager.
Tested: Got 400 error with different messages based
on failure type
{
"error": {
"@Message.ExtendedInfo": [
{
"@odata.type": "/redfish/v1/$metadata#Message.v1_0_0.Message",
"Message": "Invalid file uploaded to /redfish/v1/UpdateService: Invalid archive.",
"MessageArgs": [
"/redfish/v1/UpdateService",
"invalid archive"
],
"MessageId": "OpenBMC.0.1.0.InvalidUpload",
"Resolution": "None.",
"Severity": "Warning"
}
],
"code": "OpenBMC.0.1.0.InvalidUpload",
"message": "Invalid file uploaded to /redfish/v1/UpdateService: Invalid archive."
}
}
{
"error": {
"@Message.ExtendedInfo": [
{
"@odata.type": "/redfish/v1/$metadata#Message.v1_0_0.Message",
"Message": "Invalid file uploaded to /redfish/v1/UpdateService: Invalid image format.",
"MessageArgs": [
"/redfish/v1/UpdateService",
"invalid image format"
],
"MessageId": "OpenBMC.0.1.0.InvalidUpload",
"Resolution": "None.",
"Severity": "Warning"
}
],
"code": "OpenBMC.0.1.0.InvalidUpload",
"message": "Invalid file uploaded to /redfish/v1/UpdateService: Invalid image format."
}
}
{
"error": {
"@Message.ExtendedInfo": [
{
"@odata.type": "#Message.v1_0_0.Message",
"Message": "The resource /redfish/v1/UpdateService was unable to satisfy the request due to unavailability of resources.",
"MessageArgs": [
"/redfish/v1/UpdateService"
],
"MessageId": "Base.1.4.0.ResourceExhaustion",
"Resolution": "Ensure that the resources are available and resubmit the request.",
"Severity": "Critical"
}
],
"code": "Base.1.4.0.ResourceExhaustion",
"message": "The resource /redfish/v1/UpdateService was unable to satisfy the request due to unavailability of resources."
}
}
Change-Id: Ida9a23c10aedbf9a48c96f4050a04e06bddff284
Signed-off-by: James Feist <james.feist@linux.intel.com>
|
|
This implements the Redfish PasswordChangeRequired handling. See
section 13.3.7.1 "Password change required handling" in the 1.9.1 spec:
https://www.dmtf.org/sites/default/files/standards/documents/DSP0266_1.9.1.pdf
These portions of the spec are implemented:
- Authenticatation with a correct but expired password creates a
session:
- The session is restricted to the ConfigureSelf privilege which
allows a user to change their own password (via GET and PATCH
Password for their own account). Support for the ConfigureSelf
privilege is already in BMCWeb.
- The session object has the PasswordChangeRequired message.
- All other operations respond with http status code 403 Forbidden
and include the PasswordChangeRequired message.
- The ManagerAccount (URI /redfish/v1/AccountService/Accounts/USER)
PasswordChangeRequired property is implemented for local accounts
but not present for remote accounts.
This has the following additional behavior:
The PasswordChangeRequired property is updated at the start of each new
REST operation, even within an existing session. This behavior
implements a "dynamic" PasswordChangeRequired handling that responds to
changes to the underlying "password expired" status. Specifically:
- Sessions restricted by the PasswordChangeRequired handling lose that
restriction when the underlying account password is changed.
- Sessions become subject to the PasswordChangeRequired handling
restrictions whenever the underlying account password expires.
- The mechanism is to check if the password is expired at the start of
every new REST API operation, effectively updating the ManagerAccount
PasswordChangeRequired property each time. This makes BMCWeb
responsive to changes in the underlying account due to other activity
on the BMC.
Notes:
1. Note that when an account password status is changed (for example,
the password becomes expired or is changed) and that account has
active sessions, those sessions remain. They are not deleted. Any
current operations are allowed to complete. Subsequent operations
with that session pick up the new password status.
2. This does not implement OWASP recommendations which call for sessions
to be dropped when there is a significant change to the underlying
account. For example, when the password is changed, the password
becomes expired, or when the account's Role changes. OWASP's
recommendation is due to the session fixation vulnerability. See the
OWASP Session Management Cheat Sheet section "Renew the Session ID
After Any Privilege Level Change":
https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#renew-the-session-id-after-any-privilege-level-change
BMCWeb protects against session fixation vulnerabilities because it
always regenerates new session IDs when successful authentication
creates a new session.
3. Users authenticating via mTLS are not subject to the
PasswordChangeRequired behavior because mTLS takes precedence over
password-based authentication.
Tested:
0. Setup:
- The `passwd --expire USERNAME` command was used to expire
passwords. The `chage USER` command was also used.
- The following were used to change the password: Redfish API,
passwd command, and the SSH password change dialog.
- Tested the following via Basic Auth, /login, and Redfish login
(except where Basic Auth does not create a persistent session).
- Only local user account were tested.
- Did not test authentication via mTLS or with LDAP users.
1. When the password is not expired, authentication behaves as usual
for both correct and incorrect passwords.
2. When the password is incorrect and expired, authentication fails as
usual.
3. When the password is correct but expired:
A. A session is created and has the PasswordChangeRequired message.
B. That session cannot access resources that require Login privilege
and the 403 message contains the PasswordChangeRequired message.
C. That session can be used to GET the user's account, PATCH the
Password, and DELETE the session object.
D. The account PasswordChangeRequired reports true.
4. While a session is established, try expiring and changing
(unexpiring) the password using various mechanisms. Ensure both the
session object and the ManagerAccount PasswordChangeRequired property
report the correct condition, and ensure PasswordChangeRequired
handling (restricting operations to ConfigureSelf when
PasswordChangeRequired is true) is applied correctly.
Signed-off-by: Joseph Reynolds <joseph-reynolds@charter.net>
Change-Id: Iedc61dea8f949e4b182e14dc189de02d1f74d3e8
|
|
The type shouldn't have the path in it.
Tested: Validator passed in Task schema
Change-Id: Ic57c0450ee36799b0427e21038922f8a44c85c6e
Signed-off-by: James Feist <james.feist@linux.intel.com>
|
|
Right now all error messages requires a response object,
so they cannot be used directly in the json body. This
pulls the messages out into their own function so that
they can be used at any place in the response body.
Tested: It compiles and runs, verified return codes look
ok
Change-Id: I500b2164b2366086d610f0fdc8fa22985183e438
Signed-off-by: James Feist <james.feist@linux.intel.com>
|
|
Tested by:
Request: Creating session with wrong credential.
curl --insecure -X POST -D headers.txt https://${BMC_IP}/redfish/v1/SessionService/Sessions
-d '{"UserName":"root", "Password":"penBmc"}'
Resonse Error code: HTTP/1.1 401 Unauthorized
Signed-off-by: Sunitha Harish <sunithaharish04@gmail.com>
Change-Id: I9c7b0af644f1e3d987b4f76e4206bbb276aba035
|
|
Whenever the Redfish response is that a service is temporarily
unavailable, the "Retry-After" header is added with the same
value, so just set the header automatically with the response.
Tested:
Confirmed that the "Retry-After" header is set correctly with
the Redfish temporarily unavailable message.
Change-Id: I9c940be94d9d284b9633c5caa2ce71ade76d22d5
Signed-off-by: Jason M. Bills <jason.m.bills@linux.intel.com>
|
|
Recently, a number of people in the community have made the (admittedly
easy) mistake that we use a significant portion of crow.
Today, we use crow for the router, and the "app" structure, and even
those have been significantly modified to meet the bmc needs. All other
components have been replaced with Boost beast. This commit removes the
crow mentions from the Readme, and moves the crow folder to "http" to
camouflage it a little. No code content has changed.
Tested:
Code compiles. No functional change made to any executable code.
Signed-off-by: Ed Tanous <ed.tanous@intel.com>
Change-Id: Iceb57b26306cc8bdcfc77f3874246338864fd118
|
|
Code was tabbed into the wrong spot as a result of shutting clang-format
off for a dubious reason. Turn it back on.
Tested: It builds. Only whitespace changes present
Signed-off-by: Ed Tanous <ed.tanous@intel.com>
Change-Id: I08b294ca5ea076f8cb5680b801b507127e091824
|
|
CI gives a warning for invalid case style in variable names. This
fixes the warnings that show up so far.
Change-Id: I2a8706d3283bdc685dc026391de715accea7b86e
Signed-off-by: Jason M. Bills <jason.m.bills@linux.intel.com>
|
|
res.success is the default, if one async call
sets failure, and another later sets success, we
don't want to overwrite the failure with sucess.
Tested-by: still got success on good patch
Change-Id: Iee76892f7517d508ed98929d9ecd127dd83b1329
Signed-off-by: James Feist <james.feist@linux.intel.com>
|
|
Per the Redfish API Specification, the MessageArgs array of
strings is required when using a MessageId for a
parameterized message.
This change adds the MessageArgs array for the Redfish messages
that we use from the Base message registry.
Tested: Manually set various error types and confirmed that the
MessageArg array was properly displayed.
Change-Id: I2248128f8290305ba3466ef2ce57447ce970a57d
Signed-off-by: Jason M. Bills <jason.m.bills@linux.intel.com>
|
|
The error message code used a json_pointer object which must
begin with a '/' character and had to be sent as an extra
parameter. This change simplifies the interface by using a
string so there doesn't have to be a '/'. This allowed the
same property argument passed for the message to be used
for the property field path.
Tested: Sent an error with a property and verified that it is
correctly displayed.
Change-Id: I0571e2eee627cedf29d751588a4f1bceee66f084
Signed-off-by: Jason M. Bills <jason.m.bills@linux.intel.com>
|
|
Update the Redfish error_messages from Base.1.2.0 to Base.1.4.0
from the Redfish standard registries.
Change-Id: I771b119372fd995bd1dc4065830485b6a848f086
Signed-off-by: Jason M. Bills <jason.m.bills@linux.intel.com>
|
|
clang-format doesn't automatically merge multi-line string
literals, so this change updates the formatting to merge some
multi-line strings into fewer lines.
This change also corrects the <argx> numbering in the error message
descriptions to match the function parameter numbers.
Change-Id: Ibedcaf5793a607acacdb3bc83081599ba508c989
Signed-off-by: Jason M. Bills <jason.m.bills@linux.intel.com>
|
