|
|
Post by AMI_Mani on Aug 10, 2022 18:39:37 GMT
Hi,
Below is the response for create session
HTTP/1.1 201 Created
Location: /redfish/v1/SessionService/Sessions/1
X-Auth-Token: <session-auth-token>
{
"@odata.id": "/redfish/v1/SessionService/Sessions/1",
"@odata.type": "#Session.v1_0_0.Session",
"Id": "1",
"Name": "User Session",
"Description": "User Session",
"UserName": "<username>",
"Password": null
Is it mandatory to show password attribute with null value in post response?
Would like to know purpose of showing Password with null value for post respone
Thanks,
Mani
|
|
|
|
Post by jautor on Aug 10, 2022 20:32:44 GMT
No, it is not mandatory, and not recommended, either. Since the user cannot perform a GET on a Session resource without already authenticating, it doesn't serve any purpose to show in the payload. But it is valid, so not a problem... Password is shown in the ManagerAccount resource so that the user knows the name of the password property in order to PATCH to update it correctly. It's defined in the Session schema as it needs to be part of a POST to create a new Session - and the "null on read" is a common description for all instances of "Password" in the Redfish data model.
Jeff
|
|
|
|
Post by AMI_Mani on Aug 11, 2022 7:02:25 GMT
Hi Jeff,
Thanks for the details and "Password": null was shown as sample in Redfish Specification DSP0266_1.15.1.pdf ( 13.3.4.2 Session login)
Please remove password from sample response if not required which can avoid confusion.
As from your reply, I understand it's not recommonded to show "Password": null in response(payload) of Post sessionservice's Sessions resource collection
Thanks,
Mani
|
|
|
|
Post by mraineri on Aug 11, 2022 14:30:42 GMT
In my opinion, I don't see the harm in leaving "Password": null in the GET response to the Session resource. It does convey it's a supported property. While it is ultimately something a user cannot do anything with after a Session resource has been created, it does provide consistency in the data model in terms of a client provides a property in a create operation, and it does see it in the new resource (although it's null in this case). But as Jeff pointed out, it's not mandatory, so if you want to omit it, then that's entirely legal. I see this as akin to the "HttpHeaders" property in EventDestination; it's null in responses to show support for the property and keeps the GET response as parallel as possible to what the client specified in the POST operation, but it's not configurable.
|
|
