PATCH requests do not perform attribute type validation

[CazSaa]

When sending a PATCH request with an attribute value of the wrong type, scimitar accepts it silently and returns 200 OK. The same invalid payload sent via POST or PUT is correctly rejected with 400 InvalidValue.

Example: the active field is declared as type: boolean in the SCIM User schema. Sending "active": "yes" (a string) behaves inconsistently across methods:

Method	Payload	Response
POST /Users	"active": "yes"	400 — Active has the wrong type. It has to be a(n) boolean.
PUT /Users/:id	"active": "yes"	400 — Active has the wrong type. It has to be a(n) boolean.
PATCH /Users/:id	"active": "yes"	200 OK ← bug

Root cause

POST and PUT both go through the private with_scim_resource helper, which constructs a Scimitar::Resources::User from the request body and calls .valid? on it before yielding to the controller block. Type errors are caught there.

PATCH (in ResourcesController#update) only calls validate_request() — which checks that the body is non-empty — and then yields the raw params hash directly:

def update(&block)
  validate_request()
  render(json: yield(safe_params[:id], safe_params.to_hash()))
end

No Resources::User object is ever constructed for PATCH, so .valid? is never called and schema type validation is skipped entirely. This means any attribute in a PATCH body can be set to a value of the wrong type without error.

Expected behaviour: PATCH should validate attribute types (and other schema constraints) in the same way POST and PUT do, returning 400 invalidValue when a value does not match the declared type.

---

I wanted to confirm this wasn't caused by any of my project's overrides so I had Claude cook up a minimal repro

[CazSaa]

hey @pond , friendly reminder in case you missed this :)

[pond]

Yeah sorry, I've been slammed :-(

[pond]

An update after some digging:

The base ResourcesController is model-agnostic. It yields to a subclass to actually action something like an addition or an update. In the case of creation, it is able to validate at a SCIM resource level because it can construct it completely from the input parameters; it's a "complete" creation action. But for updates, the parameters are not complete. It isn't possible to construct a full SCIM resource and validate at the SCIM level. There is no way to retrieve a resource as a starting point and then apply the SCIM patch data to it, because that's the subclasses job; the base class doesn't know how to retrieve or update whatever is being used for persistence "below" the SCIM layer.

The intent originally was that e.g. an ActiveRecord-backed controller would assign attributes to a model and if you've, say, assigned a boolean to a string field - well, that's what your ActiveRecord model validations are for. But on the flip side, this was always a difficult design issue because it did mean inconsistency - SCIM-level validation would occur for creation, before yielding to the subclass (which may then apply further validations - or not), but there would be no such SCIM level validation for updates. It's just one of those "forever shortcomings".

(More generally, any on-save failure in the ActiveRecord-backed controller is caught as an exception and turned into a SCIM error response).

This is why it isn't as simple as using the same validation approach you see for creation. There's simply no way from the input parameters to construct a full resource. Because the SCIM specification is so insanely complicated in the numerous ways that paths to attributes can be specified, it's also quite hard to write a bespoke validator that tries to only validate the updated fields - you need a great deal of work just to figure out what those fields were.

I'm still thinking about whether this is worth implementing - I mean, it'd clearly be a good idea, I just mean in terms of effort and complexity - versus just noting in docs that application-side data stores are encouraged to validate comprehensively even if this means effectively doubling up on things that are expected to be asserted by the SCIM layer.