Hi Sam,

Are we planning to change the ownership of the generated application token
owner as well?  i.e AUTHZ_USER of the token and USERNAME of Oauth App in
the DB tables. Otherwise, for analytics, these changes wouldn't be
reflected right?

On Mon, Dec 18, 2017 at 8:21 AM, Prasanna Dangalla <[email protected]>
wrote:

> Hi Sam,
>
> +1 to have the new scope app_manage.
>
> On Mon, Dec 18, 2017 at 7:59 AM Sam Sivayogam <[email protected]> wrote:
>
>> On Sun, Dec 17, 2017 at 1:22 PM, Malintha Amarasinghe <[email protected]
>> > wrote:
>>
>>> Hi Sam,
>>>
>>> This overall looks good to me. Added few inline comments.
>>>
>>> On Sun, Dec 17, 2017 at 6:26 AM, Sam Sivayogam <[email protected]> wrote:
>>>
>>>> Hi All,
>>>>
>>>> As discussed in mail thread[1] we had a requirement to add an API which
>>>> allows to change the owner of a created application. During the initial
>>>> discussions we decided to add this api to the existing admin REST APIs.
>>>> After going through the APIs I thought to add below 2 resources.
>>>>
>>>>
>>>> 1. The following GET resource will list all the apis created by the
>>>> given user. This will be same as the store application listing API but
>>>> lists application for the given username rather than listing the
>>>> applications created user associated with the provided access token.
>>>>
>>>> This will return the
>>>> GET  /applications
>>>>
>>>> Parameters
>>>> query username
>>>>
>>>
>>> As a usual practice it is better not to mandate username as it is a
>>> query parameter. One option is, if it is not provided, we get the user from
>>> the access token. Even if it is sligtly bad that it make not sometimes make
>>> sense to get store applications of an admin user, I think it is better than
>>> fully mandating the query param and giving an error if user does not
>>> provide it.
>>>
>> +1 for this approach
>>
>>>
>>>
>>>>
>>>>
>>>> Sample Response :
>>>> {
>>>>    "count": 2,
>>>>    "next": "",
>>>>    "previous": "",
>>>>    "list":    [
>>>>             {
>>>>          "applicationId": "b16ce8d0-5e0b-4259-96e2-68151cc92489",
>>>>          "name": "AppX",
>>>>          "subscriber": "admin",
>>>>          "throttlingTier": "Unlimited",
>>>>          "description": "",
>>>>          "status": "APPROVED",
>>>>          "groupId": ""
>>>>       },
>>>>             {
>>>>          "applicationId": "aac0df98-8e26-4dda-b0ba-d794c98249c2",
>>>>          "name": "AppY",
>>>>          "subscriber": "admin",
>>>>          "throttlingTier": "Unlimited",
>>>>          "description": null,
>>>>          "status": "APPROVED",
>>>>          "groupId": ""
>>>>       }
>>>>    ]
>>>> }
>>>>
>>>>
>>>> 2. Following POST Resource is similar to the one we have for lifecycle
>>>> change. This will change the owner of the given application
>>>>
>>> In 3.0.0, we have slighly change the format of similar queries. For ex:
>>>
>>> '/applications/{applicationId}/map-keys':
>>>
>>> instead of using
>>>
>>>  '/applications/map-keys?applicationId=<id>':
>>>
>>> Since this is a new API in admin, I think first approach is better as
>>> that is the approach we will be following most of the time for 3.0.0 and
>>> there will be less amount of API changes for a user migrating from 2.x to
>>> 3.0.0
>>>
>> Will follow the first approach.
>>
>>>
>>>
>>>
>>> On Sun, Dec 17, 2017 at 1:12 PM, Godwin Shrimal <[email protected]> wrote:
>>>
>>>> Hi Sam,
>>>>
>>>> Who can change the owner of the application?
>>>>
>>>
>>> *@Godwin*, I think we will be defining a new scope for the API which
>>> can only be retrieved from an admin user. *@Sam* will we do that?
>>>
>> yes thought of having a separate scope like apim:app_manage
>>
>>>
>>>
>>>>
>>>> Thanks
>>>> Godwin
>>>>
>>>
>>>
>>> Thanks!
>>> Malintha
>>>
>>> POST /applications/change-owner
>>>>
>>>> Parameters
>>>> query application UUID
>>>> query newOwner
>>>>
>>>> Sample Response :
>>>>
>>>> {
>>>>    "applicationId": "6edcac5e-4df3-42fe-8a21-07c114085bcb",
>>>>    "name": "AppY",
>>>>    "subscriber": "newOwner",
>>>>    "throttlingTier": "Unlimited",
>>>>    "callbackUrl": null,
>>>>    "description": "",
>>>>    "status": "APPROVED",
>>>>    "groupId": ""
>>>> }
>>>>
>>>> Please let me know your thoughts on this.
>>>>
>>>> [1] Application Sharing support for Multiple Groups
>>>>
>>>> Thanks,
>>>> Sam
>>>>
>>>>
>>>> --
>>>> *Sam Sivayogam*
>>>>
>>>> Senior Software Engineer
>>>> Mobile  : +94 772 906 439
>>>> Office   : +94 112 145 345
>>>> *WSO2, Inc. :** wso2.com <http://wso2.com/>*
>>>> lean.enterprise.middleware.
>>>>
>>>
>>>
>>>
>>> --
>>> Malintha Amarasinghe
>>> *WSO2, Inc. - lean | enterprise | middleware*
>>> http://wso2.com/
>>>
>>> Mobile : +94 712383306 <+94%2071%20238%203306>
>>>
>>
>>
>>
>> --
>> *Sam Sivayogam*
>>
>> Senior Software Engineer
>> Mobile  : +94 772 906 439
>> Office   : +94 112 145 345
>> *WSO2, Inc. :** wso2.com <http://wso2.com/>*
>> lean.enterprise.middleware.
>>
> --
> *Prasanna Dangalla*
> Senior Software Engineer, WSO2, Inc.; http://wso2.com/
> lean.enterprise.middleware
>
>
> *cell: +94 718 11 27 51*
> *twitter: @prasa77*
>



-- 
Thanks & Regards,

*Fazlan Nazeem*
Senior Software Engineer
WSO2 Inc
Mobile : +94772338839
<%2B94%20%280%29%20773%20451194>
[email protected]
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to