Content-type header not respecting Accept header for application/scim+json

[wooly]

Hi there,

We're trying to use the Microsoft Azure AD SCIM Validator tool here, and we're coming across an issue as shown in the screenshot below:

Testing this in postman, when setting the Accept header in the request to the /Users endpoint, we get a json response, but the content-type header isn't using application/scim+json, which I'm guessing is what the validator is expecting?

Is there anything we can do to set the response content-type header to application/scim+json to appease the validator?

Thanks!

[chaskett]

@pond any chance you have any thoughts on this? :-)

[pond]

Not much time to look into this, but in the short term, your controllers could add a before_action filter that does something like:

response.set_header('CONTENT_TYPE', Mime::Type.lookup_by_extension(:scim).to_s)

...as a blunt force solution, perhaps evolving that if you wish to detect Accept in Request. It's probably something that Scimitar's base controllers out to do via render, if it's not happening already, but a quick glance though specs didn't make that too clear (other than MDN implying that if Accept is present in general then Content-Type ought to respond with the chosen content type - but if you only accept one thing, there's not much of a choice). It'll be down to Rails just responding by default with application/json; charset=utf-8 when render :json is used (and that might override your before-action... In which case maybe after-action!).

[chaskett]

Thanks! I will aim to feedback what how we solve this.

[wooly]

We've ended up patching the Scimitar application controller's add_mandatory_response_header method to add the CONTENT_TYPE header like you suggested 👍

[kwent]

Running into the same issue. @wooly could you share a snippet of code of the patch ?

[wooly]

@kwent it's a one-liner here: e684359

We're running our own fork of scimitar with this patch and another couple of patches to satisfy the Microsoft Scim Validator if you get stuck there too.

[pond]

This is (well, should be!) fixed by #85.

[pond]

I've pushed v2.6.1 including #85 now, along with v1.7.1 which back-ports the fix via #86.