|
Post by mraineri on Feb 12, 2024 13:40:28 GMT
In that case, yes; if all 10 supplied URIs in @odata.id are invalid, then showing 10 messages would be accurate. While it might seem extraneous, consider this: what if 5 were correct and 5 were invalid? You would have 5 specific messages with 5 related properties pointing to the exact ones that are wrong, thus the client knows the other ones in the request are okay.
However, you also need to consider other types of client request issues. For example, if the client provided a JSON object for "MetricReportDefinitions" instead of an array, then you'd only use "/MetricReportDefinitions" as the related property.
|
|
|
Post by mraineri on Feb 9, 2024 20:29:46 GMT
Response 2 would be correct.
RFC6901 specifies 0-based indexing of arrays when making a JSON path. In addition, while @odata.id is a special property, it's still the property that is in question with regards to what is wrong with the client request.
|
|
|
Post by mraineri on Feb 7, 2024 21:30:56 GMT
/redfish/v1/Chassis/{ChassisId}/NetworkAdapters/{NetworkAdapterId}/NetworkDeviceFunctions/{NetworkDeviceFunctionId}/EthernetInterfaces/{EthernetInterfaceId} is specifically for non-system types of interfaces. One example is an EBOF where there are network controllers embedded in an enclosure that serve as an NVMe-oF to PCIe bridge; there's no ComputerSystem here since it's a box of network-connected drives, but a user needs to be able to configure the IP address of those controllers. We have this in the long description for EthernetInterfaces in NetworkDeviceFunctions:
> This property shall not be present if this network device function is not referenced by a NetworkInterface resource.
For the case you're describing, you'd need to add EthernetInterface resources subordinate to the appropriate ComputerSystem resource to go alongside the NetworkInterface resources.
I'll admit this is not the most intuitive approach. We expected NetworkInterface, NetworkDeviceFunction, and other advanced communication device resources to replace EthernetInterface in the same manner Storage can fully replace SimpleStorage. Unfortunately as new use cases came up (virtual NICs, bonding, virtual machines, etc), we realized that EthernetInterface is still needed, and we likely would have taken a different modeling approach had this been apparent to us.
|
|
|
Post by mraineri on Feb 7, 2024 14:05:20 GMT
Yes, you can still use that action to change the password even if RequireChangePasswordAction is false. "RequireChangePasswordAction" only affects the ability to PATCH the Password property directly.
|
|
|
Post by mraineri on Feb 6, 2024 22:07:07 GMT
What exactly is your use case for allowing a user to add/delete/edit files on a system? SNIA does touch on some of these concepts with their file system modeling, but it doesn't go down to the level you're thinking of.
I have concerns with this sort of functionality since it's duplicative of other tools used to log into a system and edit files, like using SSH to the host and editing files over that interface. The OS already carries around permissions for who can access each of the files, and allowing Redfish to bypass the OS/recreate access rights for system files might be very problematic.
|
|
|
Post by mraineri on Feb 6, 2024 13:46:32 GMT
Thanks for pointing this out to us! We will need to fix this when we do our next publication.
|
|
|
Post by mraineri on Feb 6, 2024 13:45:26 GMT
"PropertyNotWritable" would make sense to me since in that state the property effectively becomes read-only.
|
|
|
Post by mraineri on Feb 5, 2024 13:47:30 GMT
Yes, it will update DateTime too; DateTimeLocalOffset is just the offset portion of DateTime, so modifying DateTimeLocalOffset indirectly modified DateTime.
|
|
|
Post by mraineri on Feb 5, 2024 13:44:00 GMT
Yes, you can use 204 in that manner. There's nothing requiring the task monitor to return 200 OK when the operation is complete; it's entirely context driven.
|
|
|
Post by mraineri on Feb 2, 2024 15:11:12 GMT
We have that scenario called out in the long description of the DateTimeLocalOffset property:
> If both DateTime and DateTimeLocalOffset are provided in modification requests, services shall apply DateTimeLocalOffset after DateTime is applied.
So, there's a bit of special handling required if the client provides both in a single PATCH request.
|
|
|
Post by mraineri on Feb 2, 2024 15:08:14 GMT
Yes, this would have to be by some other means; sniffing network packets is very unlikely.
One of the scenarios raised was specific to browser-based clients that might keep a session open. If a terminal with the browser is left unlocked, someone could walk up and perform those operation. It's extra protection like how when you log into a website and want to edit the password for your account, the website will prompt you for your current password too to ensure you really are the account owner.
Yes, you're right that this really is the admin's problem, but folks saw value in this as a means to help give admins a bit of a safety net for situations like this.
|
|
|
Post by mraineri on Feb 1, 2024 14:18:57 GMT
It's the second; if someone somehow obtained a valid session token for an admin, they could change the admin's password with a PATCH operation and not need to know their current password. In this case, the attacker has effectively taken over system and the real administrator cannot log back into the service, which makes recovery impossible without other means of intervention.
At the very least, any admin can close open sessions if they believe a session token has been leaked. But you're correct; if someone has somehow obtained a valid session token for an admin, they can do other types of operations. But at least the admin's password is still valid and they can take recovery actions.
|
|
|
Post by mraineri on Feb 1, 2024 14:14:04 GMT
Yes, it is confusing. No one likes it, but we're stuck here since changing it would break backwards compatibility.
|
|
|
Post by mraineri on Jan 30, 2024 14:50:41 GMT
Given the semantics of the PATCH operation on this property, you'd have to activate the power limit behind the scenes. Keep in mind, Redfish and IPMI aren't necessarily one-for-one; if you need to support both protocols, there will be cases where some operations in Redfish will cause multiple things to happen in IPMI, and vice versa.
|
|
|
Post by mraineri on Jan 30, 2024 14:30:08 GMT
The "Redfish-defined URIs and relative reference rules" clause calls out the form "/redfish/v1/TaskService/TaskMonitors/<TaskMonitorId>" for task monitor URIs.
|
|