Hi Johann,
When we send data within double quotations since the quotations are dropped
by curl, we get the payload as follows.
*{schemas: [urn:scim:schemas:core:1.0], name : {familyName:
Tester},userName: hasinitg,meta: {attributes: []}}*
So when we try to parse the schemas array in payload, JSON decoder expects
a comma or a square closing bracket after urn:scim and not another colon.
This is the reason for JSON parsing exception when using double quotes.
Thanks,
Sathya
On Wed, Aug 16, 2017 at 12:57 PM, Pulasthi Mahawithana <[email protected]>
wrote:
> Hi Johann,
>
> I also experienced this same problem with double quote sometime back. Yes,
> it's because the way curl works. When double quotes are used, curl was
> dropping the quotes. However, due to the way we parse the payload, it still
> worked as long as we don't have any character troubling the json structure.
> So, here I assume the ':' characters in "urn:scim:schemas:core:1.0" were
> causing the issue (when double quote is used).
>
> On Wed, Aug 16, 2017 at 12:42 PM, Johann Nallathamby <[email protected]>
> wrote:
>
>>
>>
>> On Wed, Aug 16, 2017 at 12:33 PM, Sathya Bandara <[email protected]> wrote:
>>
>>> Hi,
>>>
>>> The issue [1] occurs due to invalid data format. It is not identified as
>>> a bug since as mentioned in the doc, similar to user create requests, we
>>> need to include json data within single quotations and not double
>>> quotations to avoid json parsing exceptions.With the correct format it is
>>> possible to include non-empty schema attributes with the request.
>>>
>>> eg:
>>>
>>> *request:*
>>> curl -v -k --user admin:admin -X PATCH -d '{"schemas":
>>> ["urn:scim:schemas:core:1.0"],"name":{"familyName": "Tester"}
>>> ,"userName": "hasinitg","meta": {"attributes": []}}' --header
>>> "Content-Type:application/json" https://localhost:9443/wso2/sc
>>> im/Users/15722a71-3bd1-4864-8460-1e63a2dace65
>>>
>>> *response:*
>>>
>>> {"emails":[{"type":"home","value":"hasini_home.com"},{"type"
>>> :"work","value":"hasini_work.com"}],"meta":{"created":"2017-
>>> 08-16T10:07:36","location":"https://localhost:9443/wso2/
>>> scim/Users/15722a71-3bd1-4864-8460-1e63a2dace65","lastModifi
>>> ed":"2017-08-16T12:17:11"},"schemas":["urn:scim:schemas:core:1.0"]
>>> ,"name":{"familyName":"Tester","givenName":"hasini
>>> tg"},"id":"15722a71-3bd1-4864-8460-1e63a2dace65","userName":"hasinitg"}
>>>
>>
>> This seems a bit weird to me. If it's a JSON parsing problem then double
>> quotes should not work for any kind of data JSON data. How come it is
>> working for empty array?
>>
>> Is this double quote problem something related to how curl works? If we
>> use a HTTP client don't we have this issue? If it's a curl problem then we
>> shouldn't worry I suppose.
>>
>> Regards,
>> Johann.
>>
>>
>>> [1] https://wso2.org/jira/browse/IDENTITY-6271
>>>
>>> Thanks,
>>> Sathya
>>>
>>> On Wed, Aug 16, 2017 at 11:37 AM, Gayan Gunawardana <[email protected]>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Aug 15, 2017 at 10:44 PM, Johann Nallathamby <[email protected]>
>>>> wrote:
>>>>
>>>>> IAM Team,
>>>>>
>>>>> I found below two critical issues in IS 5.3.0 SCIM 1.1 implementation.
>>>>>
>>>>> 1. Users/{id} PATCH operation expects the "schemas" attribute to be
>>>>> empty. If the core schema value is given it throws an error [1].
>>>>>
>>>>> 2. "userName" attribute is mandatory in Users/{id} PATCH operation.
>>>>> This is not the case according to the spec [2].
>>>>>
>>>>> I think the first issue is a MUST fix. Because all the users who will
>>>>> try our SCIM patch implementation will face this issue and discontinue
>>>>> trying/using WSO2 IS 5.3.0. So I think this must be fixed.
>>>>>
>>>> Yes we have to look at fixing this issue in backward-compatible manner.
>>>>
>>>>>
>>>>> The second issue seems to be a problem with our implementation design.
>>>>> I don't know if this could be easily fixed. May be it can be fixed at the
>>>>> cost of performance. Someone has to check on this. But if that is the case
>>>>> what is going to be our stance here? Compliance vs. Performance. Which
>>>>> side
>>>>> do we take? I would say compliance is more important. What are your
>>>>> thoughts?
>>>>>
>>>> We can fix this issue as well but need to check for API changes.
>>>>
>>>>>
>>>>> [1] https://wso2.org/jira/browse/IDENTITY-6271
>>>>> [2] https://wso2.org/jira/browse/IDENTITY-6272
>>>>>
>>>>> Thanks & Regards,
>>>>> Johann.
>>>>>
>>>>> --
>>>>>
>>>>> *Johann Dilantha Nallathamby*
>>>>> Senior Lead Solutions Engineer
>>>>> WSO2, Inc.
>>>>> lean.enterprise.middleware
>>>>>
>>>>> Mobile - *+94777776950*
>>>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Gayan Gunawardana
>>>> Senior Software Engineer; WSO2 Inc.; http://wso2.com/
>>>> Email: [email protected]
>>>> Mobile: +94 (71) 8020933
>>>>
>>>
>>>
>>>
>>> --
>>> Sathya Bandara
>>> Software Engineer
>>> WSO2 Inc. http://wso2.com
>>> Mobile: (+94) 715 360 421 <+94%2071%20411%205032>
>>>
>>> <+94%2071%20411%205032>
>>>
>>
>>
>>
>> --
>> Thanks & Regards,
>>
>> *Johann Dilantha Nallathamby*
>> Senior Lead Solutions Engineer
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - *+94777776950*
>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>>
>> _______________________________________________
>> Dev mailing list
>> [email protected]
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Pulasthi Mahawithana*
> Senior Software Engineer
> WSO2 Inc., http://wso2.com/
> Mobile: +94-71-5179022 <+94%2071%20517%209022>
> Blog: https://medium.com/@pulasthi7/
>
> <https://wso2.com/signature>
>
--
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>
<+94%2071%20411%205032>
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev
