Post by josephreynolds1 on Nov 8, 2019 21:19:47 GMT
I am trying to determine the correct message to send when the AccountService Password property fails to PATCH. I would like to return enough information for a Web GUI front end to distinguish between temporary PAM malfunctions (such as /etc/passwd locked) and the new password not meeting complexity requirements. Specifically, OpenBMC uses Linux PAM function pam_chauthtok which returns PAM_AUTHTOK_ERR for any number of reasons, including the common case of the new password not meeting complexity requirements. I want to know which message to send for this return code.
The AccountNotModified message applies, but is too vague. I wish for something more specific.
The propertyValueNotInList message refers to enum types.
The PropertyValueFormatError messsage is very close, but talks about the property's format. I need to talk about the property's value. Also, if I wanted to use this message for the Password property, I would want to redact the value.
I need a message like: PropertyValueError - The value for the property %1 was not accepted by the service.
"Correct the value for the property in the request body and resubmit the request if the operation failed."
Post by josephreynolds1 on Nov 11, 2019 20:12:29 GMT
To clarify: I understand HTTP status 400 should be used and I think the AccountNotModified message should be given in this case. I am interested in the correct solution. At the same time, I am thinking about a quick hack solution: Add an ["Oem"]["IBM"] field to the AccountNotModified message which states something like: "The new password was not accepted. A possible cause is the password value failed PAM validation checks." I would give additional information, such as: the password is not complex enough, was re-used too soon, etc.m but I don't know how to get that level of details.
If I tried to PATCH a new password into my account and got AccountNotModified with the explanation above, I might be tempted to try a different password. And that is what I want. Is that direction correct for Redfish?
Post by josephreynolds1 on Nov 14, 2019 23:14:17 GMT
I've now turned to this solution: When Linux PAM function pam_chauthtok (change password) returns PAM_AUTHTOK_ERR, give the Redfish AccountNotModified message with the optional Resolution field containing something like: > The password was not accepted. Try again with a different value. Does that solution comply with the Redfish spec?
I am still struggling with how to provide more information about why the API failed. For example, I wuld like to give a more specific reason, but I am limited by what PAM tells me. Is there a better solution?
I think we want to have a message in the Base message registry for this case (and others) where a property value is not correct. It could be due to a regex violation per the patterns term, password complexity rules, or some other problem. But essentially we need something more deterministic for a client to know a value is not correct.
Post by josephreynolds1 on Nov 22, 2019 17:21:45 GMT
I've re-asked this question in the OpenBMC email list (https://lists.ozlabs.org/pipermail/openbmc/2019-November/019600.html) excerpted here. Does this sound right?
Here are ideas for a straw-man draft for a new Redfish standard message - Id: PropertyValueError - Message: The value XYZ for the property ABC was not accepted. - Resolution: Correct the value for the property in the request body and resubmit the request if the operation failed. Additional information about the cause may be provided in the ExtendedInfo.
Then represent each possible cause as an individual [email protected] message: - "The value XYZ for the property ABC does not comply with the regular expression." - "The value for the Password property was not accepted. The reason is: %1" -- I've omitted the password value itself from the message. This was done to try to keep the value confidential. Is that warranted, or can we have a generic message (as on the next item below)? A use case for this is messages from PAM like "BAD PASSWORD: it is way too short". - "The value %1 for the property %2 was not accepted. The reason is: %3"
Each of the ExtendedInfo messages would also need a formal spec.
Post by josephreynolds1 on Nov 25, 2019 17:24:44 GMT
As a developer implementing a Redfish complaint application, where do I find guidance on how to select the right messages to respond? I see DSP0266 Redfish Spec > Service Responses > Error Responses, but I want more help. Is there anything in redfish.dmtf.org/education. Where is the right place for this?
Here is a strawman proposal for a decision tree to help the programmer decide which messages the code should send when it cannot accept a Property value in a PATCH or PUT or POST request:
A. The overall message (per DSP0266 Redfish Spec > Service Responses > Error Responses) should relate to what the user was trying to accomplish. For example, if the request was for a ManagerAccount, give the AccountNotModified message.
B. Use @message.ExtendedInfo to give details about what went wrong or how to fix the problem. One of:
1. PropertyValueTypeError, if the value has the wrong JSON type.
2. Use one of the following (the most specific message that applies to the situation):
- PropertyValueNotInList - for enum types - PropertyValueOutOfRange - for example, when the value is out of its numeric range - PropertyValueFormatError - when neither of the previous two messages apply and the format is well-defined - PropertyValueConflict, PropertyNotWritable, etc. - PropertyValueNotAccepted (PROPOSED) - when the format is not well-defined or the criteria for its acceptance can change - PasswordValueNotAccepted (PROPOSED) - a specialization of PropertyValueNotAccepted which omits the value from the message body.
Here is a proposal for the new messages: PropertyValueNotAccepted (PROPOSED) - Usage notes: Using this implies your code is using some backend service for which it cannot completely characterize the rules for valid values, or those rules change over time. A canonical example is Linux PAM which may have rules about password complexity which change over time (as the system is patched) or rules about re-using passwords. Prefer to use PropertyValueFormatError when applicable. - MessageId: Base.TBD.PropertyValueNotAccepted - Message: The new value %1 was not accepted. The reason is: %2 <-- Reason %2:string can be directly from PAM, for example, BAD PASSWORD: it is too short - ParamTypes: [string, string] Note: This message can only be used for string-type parameters.
- Usage notes: This is a specialization of the PropertyValueNotAccepted message for passwords. This omits the password value from the message. - MessageId: Base.TBD.PropertyValueNotAccepted - Message: The new password was not accepted. The reason is: %1 <-- Reason %1:string can be directly from Linux PAM, for example, "BAD PASSWORD: it is too short".
- MessageId: PropertyValueRegexError - Message: The new value %1 for the %2 property does not match regular expression: %3.
In the above, I've proposed both PropertyValueNotAccepted and PasswordValueNotAccepted. I can see a need for both, but I really only need one or the other. (I don't have a current use case for PropertyValueRegexError, but a need for it was mentioned in this thread.) I would prefer having a PasswordValueNotAccepted message so I won't have to redact the password value. I greatly prefer to limit the propagation of password values.
Here is how the response would look for my current situation (specifically, PATCH new Password fails): - error: - code: AccountNotModified - @message.ExtendedInfo: - (array) - MessageId: Base.(PROPOSAL).PasswordValueNotAccepted - Message: The new value %1 was not accepted. The reason is: %1 <-- Reason %1 can be directly from PAM, for example, BAD PASSWORD: it is too short - (array) - Or one of any number of other messages per the decision tree above.
Three questions: 1. Does the structure of my overall response look correct? Am I using AccountNotModified and (proposed) PasswordValueNotAccepted correctly? 2. Is the next step drafting a pull request to add these new messages to the spec? 3. I would like to be able to refer to a decision tree (such as outlined in this reply). I think it would help my future self and other developers in the OpenBMC project. Do you think it is worthwhile? Is there one already I am missing? Where is the right place for something like this?
Last Edit: Nov 25, 2019 17:29:58 GMT by josephreynolds1: fix bulleted list formatting errors
1. Does the structure of my overall response look correct? Am I using AccountNotModified and (proposed) PasswordValueNotAccepted correctly?
I'll take a look later, but wanted to give guidance on the overall post sooner rather than later...
2. Is the next step drafting a pull request to add these new messages to the spec?
Yes. We've been trying to capture error semantics in the (normative) specification as much as possible. For interoperability, we've been adding references to the Base Message Registry over time to provide explicit guidance on which message to use for a particular condition.
3. I would like to be able to refer to a decision tree (such as outlined in this reply). I think it would help my future self and other developers in the OpenBMC project. Do you think it is worthwhile? Is there one already I am missing? Where is the right place for something like this?
I think it's an excellent idea and certainly worthwhile. No, we don't have one in process or otherwise available. There are a couple of choices to placing this information - either in the Specification or as a section in the "Schema Supplement" (DSP0268) as both of those are normative specifications. Otherwise, a new informative document could be created for this content. I'd like this to be normative (aka specification/binding) if possible.