Attribute with null values in POST and PUT requests.

[sebastien-savalle]

Hello,

When an attribute is "required", clients MUST specify the attribute in the POST and PUT request.
Moreover, the RFC7644 says "Clients that want to override a server's defaults MAY specify "null" for a single-valued attribute.

In the extension builder, the setAttribute method remove the attribute when the value is null. In that case, the required validator returns a bad request due to missing attribute.
When the attribute is not required, there is no difference between a missing parameter and a null value. So it's not possible to know if the value must be set to null or to a default value.

Do you have any advice on how to tackle this issue ?

Thanks

[karaimin]

Hi @ellavas

I am sceptical about setting null value to required modifiable attribute, because this means that you want to remove the attribute

Clients that want to
override a server's defaults MAY specify "null" for a
single-valued attribute, or an empty array "[]" for a multi-valued
attribute, to clear all values.

Actually, this means that no value was added to this attribute
Regards

[sebastien-savalle]

Not only to required attribute.
Let's imagine the use case: You have a optional attribute (a date for example).

• When you post a new resource, the backend can set a default date (now()) when the attribute is missing.
• But the client may want to create the resource with a date set to null.

With the current implementation of the library, it's not possible to know if the client provide the attribute with a null value or if he omits the attribute to use a default one.

I think this is the assumption described in the RFC.

Then, you may want to define your attribute as required to be sure that the client sets explicitly the attribute to null.

[karaimin]

Then, you may want to define your attribute as required to be sure that the client sets explicitly the attribute to null.

Setting it to required means that the client should provide value to it in POST/PUT request.

I think that setting null means that you don't want a value to be assigned to this attribute ... and this is a conflict with the mutability level.

I agree that it looks confusing. If we can't come to an agreement It is possible to ask a question in the SCIM mailing list.

[sebastien-savalle]

Yes it could be interesting to have their feedback.

My requirements: I have to provide a user extension to block the user at a given date. This date can be modified and can also be null. In this case, the user will be never be blocked.

User is modified with a PUT, so the operation will replace all the attributes.
I can define my custom attribute "blockedAt" as not required and readWrite. In that case, if the "blockedAt" is omitted in the body of the PUT request, the previous value will be removed.
I found that approach too risky and I would rather prefer to define the "blockedAt" attribute as required, and force the client to provide a "blockedAt" value to null to remove the existing value.

This is my understanding of the RFC section

As the operation's intent is to replace all attributes, SCIM clients
MAY send all attributes, regardless of each attribute's mutability.
The server will apply attribute-by-attribute replacements according
to the following attribute mutability rules:

readWrite, writeOnly Any values provided SHALL replace the existing
attribute values.

  Attributes whose mutability is "readWrite" that are omitted from
  the request body MAY be assumed to be not asserted by the client.
  The service provider MAY assume that any existing values are to be
  cleared, or the service provider MAY assign a default value to the
  final resource representation.  Service providers MAY take into
  account whether or not a client has access to, or understands, all
  of the resource's attributes when deciding whether non-asserted
  attributes SHALL be removed or defaulted.  Clients that want to
  override a server's defaults MAY specify "null" for a
  single-valued attribute, or an empty array "[]" for a multi-valued
  attribute, to clear all values.

[karaimin]

I think, that the problem is that you want to treat null as a real value and you would like the possibility to have different behaviour for null and non-existing values. IMHO, both should be the same and use other approach to achieve the desired feature.
Before posting a question to the community, I would like to suggest you reading this. It is already existing similar discussion in the community mailing list.