Sure, Meruja, that's what 412 is all about - but I didn't see documented
that we support conditional requests, and what the semantics in our case
will be: that's why I am asking.

Best regards,
Frank




Am Di., 26. Mai 2020 um 06:56 Uhr schrieb Meruja Selvamanikkam <
mer...@wso2.com>:

> Dear Frank,
>
> We return 412 when the preconditions fail.
> The number of request headers that can be used to apply conditions to a
> request:
>
> If-Match
> If-Modified-Since
> If-None-Match
> If-Range
> If-Unmodified-Since
>
> Since my request does not contains the stated headers, there won't be 412.  
> Thanks for pointing me to clarify and correct my understanding.
>
>  412:
>           description: |
>             Precondition Failed.
>             The request has not been performed because one of the 
> preconditions is not met.
>           schema:
>             $ref: '#/definitions/Error'
> This should be removed from the response.
>
> Thanks & Regards,
> *S.Meruja* |Software Engineer | WSO2 Inc.
> (m) +94779650506 | Email: mer...@wso2.com
> Linkedin:   https://www.linkedin.com/in/meruja
> <https://www.google.com/url?q=https://www.linkedin.com/in/meruja>
> Medium: https://medium.com/@meruja
> <http://wso2.com/signature>
>
>
> On Mon, May 25, 2020 at 10:23 PM Frank Leymann <fr...@wso2.com> wrote:
>
>> Dear Meruja,
>>
>> when would we return a 412?
>>
>> Best regards,
>> Frank
>>
>>
>>
>>
>> Am Fr., 22. Mai 2020 um 15:42 Uhr schrieb Meruja Selvamanikkam <
>> mer...@wso2.com>:
>>
>>> Hi all,
>>>
>>> We are in the process of implementing an API to get the scope list of a
>>> particular user.
>>> Following will be the notations of the new API:
>>> *GET  api/am/admin/v1/settings/scopes?userId=<value>*
>>>
>>> Please find the swagger definition below:
>>>
>>>  /settings/scopes:
>>> #-----------------------------------------------------
>>> # Retrieve scope settings
>>> #-----------------------------------------------------
>>>     get:
>>>       security:
>>>         - OAuth2Security:
>>>             - apim:admin_settings
>>>       x-wso2-curl: "curl -k -H \"Authorization: Bearer
>>> ae4eae22-3f65-387b-a171-d37eaa366fa8\" -X POST \"
>>> https://localhost:9443/api/am/admin/v1/settings/scopes?userId=890a4f4d-09eb-48
>>> <https://localhost:9443/api/am/admin/v1/settings/scopes?userId=890a4f4d-09eb-4877-a323-57f6ce2ed79b%5C>
>>> ""
>>>       x-wso2-request: |
>>>         GET
>>> https://localhost:9443/api/am/admin/v1/settings/scopes?userId=890a4f4d-09eb-48
>>> <https://localhost:9443/api/am/admin/v1/settings/scopes?userId=890a4f4d-09eb-4877-a323-57f6ce2ed79b>
>>>         Authorization: Bearer ae4eae22-3f65-387b-a171-d37eaa366fa8
>>>       x-wso2-response: "HTTP/1.1 200 OK"
>>>       summary: Retrieve scopes for a particular user
>>>       description: |
>>>         This operation will return the scope list of particular user
>>>         In order to get it, we need to pass the userId as a query
>>> parameter
>>>       parameters:
>>>         - name: userId
>>>           in: query
>>>           type: string
>>>           required: true
>>>       tags:
>>>         - Settings
>>>       responses:
>>>         200:
>>>           description: |
>>>             OK.
>>>             Scopes for a particular user retrieved successfully.
>>>         400:
>>>           description: |
>>>             Bad Request.
>>>             Invalid request or validation error
>>>           schema:
>>>             $ref: '#/definitions/Error'
>>>         404:
>>>           description: |
>>>             Not Found.
>>>             Requested user does not exist.
>>>           schema:
>>>             $ref: '#/definitions/Error'
>>>         412:
>>>           description: |
>>>             Precondition Failed.
>>>             The request has not been performed because one of the
>>> preconditions is not met.
>>>           schema:
>>>             $ref: '#/definitions/Error'
>>>
>>> Highly appreciate your thoughts and suggestions.
>>>
>>> Thanks & Regards,
>>> *S.Meruja* |Software Engineer | WSO2 Inc.
>>> (m) +94779650506 | Email: mer...@wso2.com
>>> Linkedin:   https://www.linkedin.com/in/meruja
>>> <https://www.google.com/url?q=https://www.linkedin.com/in/meruja>
>>> Medium: https://medium.com/@meruja
>>> <http://wso2.com/signature>
>>>
>>>
>>> On Mon, May 11, 2020 at 9:37 PM Meruja Selvamanikkam <mer...@wso2.com>
>>> wrote:
>>>
>>>>  Hi all,
>>>>
>>>> Thank you for your suggestions
>>>>
>>>> I have a few concerns regarding validating the subscriber permissions
>>>>> of the input application owner using the default subscriber role(Internal
>>>>> subscriber). Since the REST API and portal access are based on the
>>>>> scope-role mapping which is maintained in tenant-conf.json, a subscriber
>>>>> user does not necessarily have the *Internal/subscriber* role. If a
>>>>> new role mapping to app management, subscriptions related scopes has been
>>>>> introduced with custom roles, then the validation should be done against
>>>>> those roles as well.
>>>>>
>>>>
>>>> I agree with you. For previous versions, we have a default subscriber
>>>> role in the configuration file and checked role-based permission for a
>>>> particular feature. From 3.1.0 onwards, we have a scope-role mapping.
>>>> In this case, we cannot validate the user role.
>>>>
>>>> Hence, we should be validating whether any of the roles assigned to
>>>>> that particular user has bare scope based minimum access to API
>>>>> subscriptions, app management resources. So the validation should be based
>>>>> on the role-scope mapping.
>>>>>
>>>>> ie: If the user's role 'roleA' has role-scope mappings for 
>>>>> 'apim:subscribe'
>>>>> and 'apim:app_manage' scopes, then that particular user is
>>>>> eligible as a new owner of a given application.
>>>>> WDYT?
>>>>>
>>>> Yes, we need to validate against the scope.
>>>>
>>>>
>>>> Thanks & Regards,
>>>> *S.Meruja* |Software Engineer | WSO2 Inc.
>>>> (m) +94779650506 | Email: mer...@wso2.com
>>>> Linkedin:   https://www.linkedin.com/in/meruja
>>>> <https://www.google.com/url?q=https://www.linkedin.com/in/meruja>
>>>> Medium: https://medium.com/@meruja
>>>> <http://wso2.com/signature>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>> _______________________________________________
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
> _______________________________________________
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to