-
-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PatchOp lowercases all JSON keys on a value #70
Comments
Thank you for your report. Indeed, I would indeed expect the case to be kept during the export. This might be due to However, I am not really sure how to fix this. There might be needed to add type parameterss to |
Another interesting example of this is the following patch request from https://learn.microsoft.com/en-us/entra/identity/app-provisioning/application-provisioning-config-problem-scim-compatibility. In this example, the value keys are lowercased and the PatchOp.model_validate(
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:PatchOp"
],
"Operations": [
{
"op": "replace",
"value": {
"displayName": "Bjfe",
"name.givenName": "Kkom",
"name.familyName": "Unua",
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:employeeNumber": "Aklq"
}
}
]
}
).model_dump() {
"schemas":[
"urn:ietf:params:scim:api:messages:2.0:PatchOp"
],
"Operations":[
{
"op":"replace",
"value":{
"displayname":"Bjfe",
"namegivenname":"Kkom",
"namefamilyname":"Unua",
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:user:employeenumber":"Aklq"
}
}
]
} I think a type parameter to {
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:PatchOp"
],
"Operations": [
{
"op": "replace",
"path": "emails[type eq \"work\"].value",
"value": "[email protected]"
}
]
} |
[RFC7644] (Section 3.5.2.3) lists the following example of a valid
urn:ietf:params:scim:api:messages:2.0:PatchOp
object,PatchOp.model_validate()
validates this request as expected, but it lowercases all the keys of the JSON object, meaning they no longer match the schema. I don't believe this to be correct.[RFC7644] (Section 3.10) does make a statement that
All facets (URN, attribute, and sub-attribute name) of the fully encoded attribute name are case insensitive
, and the keys of the JSON object are attributes, which is where I suspect the reasoning of lowercasing all the keys originated, but it's at odds with all other models provided by this library (e.g.User
dumpsuserName
).The text was updated successfully, but these errors were encountered: