Hi all, I have done some minor changes to the above function and injected this functionality as 'disabled' property or as conditionally rendering, into most of the Publisher components. Please find the related Wiki guide on how to implement this. We have to follow this to apply this for each input element, which are interacted in the process of editing API, in the publisher app.
[1] https://github.com/wso2/carbon-apimgt/wiki/Permission-validation-on-the-Publisher-UI-elemets-for-API-update Regards, Samitha On Sun, Sep 15, 2019 at 12:52 PM Samitha Chathuranga <sami...@wso2.com> wrote: > Hi, > > The objective has been achieved already by, > > - Adding additional property "disabled" for each editable input > element / or render the element only if adhere to the given condition > - Setting the condition value by considering the user's (token's) > scopes (whether user has apim:api_create/ apim:api_publisher). > > We have other condition to consider the update permission; that is the API > LIfeCycle status. > - i.e. if the user is a creator, he cannot update an API which is in > 'Published' state. > > In general the creator can update APIs only in ‘created’ state. (cannot > update any other states: Prototyped, Blocked, Deprecated, Retired ) > Please correct me if this should be different. > > So we can define the below function in AUthManager.js. > > static *isUpdateRestricted*(scopesAllowedToEdit, api) { > // determines whether the user is a publisher or creator (based on what > is passed from the element) > if (scopesAllowedToEdit.filter(element => > AuthManager.getUser().scopes.includes(element)).length > 0) { > // if the user has publisher role, no need to consider the api > LifeCycleStatus > if (AuthManager.getUser().scopes.includes('apim:api_publish')) { > return false; > } else if ( > // if the user has creator role, but not the publisher role > AuthManager.getUser().scopes.includes('apim:api_create') && > api.lifeCycleStatus === 'CREATED') { > return false; > } else { > return true; > } > } > return true; > } > > Then we may call this function when rendering the React input elements as > below. > > <TextField > disabled={AuthManager.*isUpdateRestricted*(['apim:api_create', > 'apim:api_publish'], api)} > .. > /> > > So we will have to call this function in each input element in the Publisher > App. > > Please raise if there is any concern > > Regards, > Samitha > > > On Mon, Aug 5, 2019 at 5:08 PM Samitha Chathuranga <sami...@wso2.com> > wrote: > >> Hi All, >> >> This is an update on the discussion points and conclusions in the meeting >> we had regarding this. >> >> - Will proceed with the above suggested approach of changing the >> existing PUT api/ resource in REST API. (discussed on using a separate >> PATCH resource, but considering the similar or more additional work >> required with that, it was discarded) >> - We will fail the request if it detects some unauthorized fields are >> going to be updated. 401 Unauthorized error will be returned in that case. >> - Change the fields that are allowed for publisher user to update. So >> those fields are, >> - Visibility on store >> - Tags >> - Docs >> - Subscription availability >> - Subscription tiers >> - Business info >> - Gateways >> - API properties >> >> (Please add if I am missing anything here) >> >> - Publisher new react app shows segments/menu items for each API >> field/artifact group in the left side navigation panel. So there is no >> separate segment for publisher's update-allowed fields. To identify them >> as >> managed fields, the related sections will be listed under a separate >> group. >> (may be separated by a horizontal line) >> >> Please add if I have missed anything. >> >> Regards, >> Samitha >> >> On Thu, Aug 1, 2019 at 11:21 AM Harsha Kumara <hars...@wso2.com> wrote: >> >>> >>> >>> On Thu, Aug 1, 2019 at 11:05 AM Samitha Chathuranga <sami...@wso2.com> >>> wrote: >>> >>>> >>>> >>>> On Tue, Jul 30, 2019 at 12:03 PM Malintha Amarasinghe < >>>> malint...@wso2.com> wrote: >>>> >>>>> >>>>> >>>>> On Tue, Jul 30, 2019 at 11:56 AM Samitha Chathuranga <sami...@wso2.com> >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> *Problem:* >>>>>> >>>>>> The objective of this task is to allow updating the authorized field >>>>>> of an API for a particular user through the Publisher REST API, through >>>>>> PUT >>>>>> /apis/{apiId}. Current behavior is that the >>>>>> REST API level web app authenticator doesn't allow updating >>>>>> individual fields considering an individual field's authorization level. >>>>>> If >>>>>> the user(user's token) doesn't have the apim:api:create >>>>>> scope (which is defined under /apis/{apiId} PUT resource, in the api >>>>>> publisher REST API swagger) the REST API level authenticator fails the >>>>>> request. >>>>>> >>>>>> The initiative behind adding this feature is that the new React based >>>>>> publisher doesn't have a separation of API fields as "Design", >>>>>> "Implement" >>>>>> and "Manage" as in 2.6.0 and all the >>>>>> operations are done though Publisher REST API (i.e. no jaggery APIs). >>>>>> As there are no separation of API fields as "Design", "Implement" and >>>>>> "Manage", it is not even possible to update >>>>>> separate sets of fields via separate calls. So the requirement arises >>>>>> that we need to improve the existing REST api to facilitate updating any >>>>>> the authorized API fields from all the fields in single call. >>>>>> >>>>>> *Solution proposed:* >>>>>> >>>>>> The tasks we have to do do address this issue are as below. >>>>>> >>>>>> - In old publisher REST API we had "x-scope" property to define >>>>>> scopes and now in new publisher, we use "OAuth2Security"property. In >>>>>> both >>>>>> the scenarios, we can define only single >>>>>> scope definition per resource. So to solve the above problem, we >>>>>> should be able to define multiple scopes per each resource. >>>>>> >>>>>> >>>>>> So the updated API Publisher REST API Swagger definition would be as >>>>>> below. >>>>>> >>>>>> /apis/{apiId}: >>>>>> --- >>>>>> >>>>>> put: >>>>>> x-wso2-curl: "curl -k -H \"Authorization: Bearer .... >>>>>> x-wso2-request: "PUT >>>>>> https://127.0.0.1:9443/api/am/publisher/v1.0/apis/7a2298c >>>>>> <https://127.0.0.1:9443/api/am/publisher/v1.0/apis/7a2298c4-c905-403f-8fac-38c73301631f%5CnAuthorization>.... >>>>>> x-wso2-response: "HTTP/1.1 200 OK\nContent-Type: >>>>>> application/json\n\n{\r\n \"id\": \"7a2298c4-c905-..... >>>>>> security: >>>>>> - OAuth2Security: >>>>>> - apim:api_create >>>>>> - apim:api_publish >>>>>> >>>>>> >>>>>> - >>>>>> >>>>>> Set the token Info into the CXF message context within >>>>>> org.wso2.carbon.apimgt.rest.api.util.impl.WebAppAuthenticatorImpl, so >>>>>> the token scopes >>>>>> can be validated in API service impl layer. >>>>>> >>>>>> - Define the required specific scope that a user needs to update >>>>>> that field, as an annotation on each API field in the APIDTO . >>>>>> >>>>>> @Scope(name = "apim:api_create", description="") >>>>>> private String wsdlUri = null; >>>>>> >>>>>> This will decide that an access token should have the scope >>>>>> "apim:api_create" to update that field. >>>>>> We can set the above annotation in the DTO by defining an >>>>>> additional property (i.e. x-allowUpdatesFor: scope:) withinn the API >>>>>> type >>>>>> definition in publisher REST API Swagger as >>>>>> below and updating the API DTO model template related pojo >>>>>> mustache file (server-templates/pojo.mustache) >>>>>> >>>>>> definitions: >>>>>> >>>>>> API: >>>>>> >>>>>> wsdlUri: >>>>>> x-allowUpdatesFor: >>>>>> scope: apim:api_create >>>>>> >>>>>> >>>>>> >>>>>> - So in ApisApiServiceImpl, when an API is going to be updated in >>>>>> apisApiIdPut(..) we may resolve the field scopes from the API DTO and >>>>>> then >>>>>> compare >>>>>> with the token's scopes. If the token doesn't have >>>>>> apim:api_create scope, then the field value will be overridden by the >>>>>> original (same old) value. Else, the passed value from body >>>>>> will be set as the new value. >>>>>> >>>>>> >>>>> Should we fail the request if it detects some unallowed fields are >>>>> updated, or ignore and overwrite and pass the request? >>>>> >>>>> Hi all, >>>> >>>> Highly appreciate your concerns on this matter. We need to finalize >>>> this matter to go forward. >>>> >>> I think it would be best to arrange a quick meeting on this. >>> >>>> Thanks! >>>>> >>>>> Please share your suggestions on this suggested solution. >>>>>> >>>>>> Regards, >>>>>> Samitha >>>>>> -- >>>>>> *Samitha Chathuranga* >>>>>> *Senior Software Engineer*, *WSO2 Inc.* >>>>>> lean.enterprise.middleware >>>>>> Mobile: +94715123761 >>>>>> >>>>>> [image: http://wso2.com/signature] <http://wso2.com/signature> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Malintha Amarasinghe >>>>> *WSO2, Inc. - lean | enterprise | middleware* >>>>> http://wso2.com/ >>>>> >>>>> Mobile : +94 712383306 >>>>> >>>> >>>> >>>> -- >>>> *Samitha Chathuranga* >>>> *Senior Software Engineer*, *WSO2 Inc.* >>>> lean.enterprise.middleware >>>> Mobile: +94715123761 >>>> >>>> [image: http://wso2.com/signature] <http://wso2.com/signature> >>>> >>> >>> >>> -- >>> >>> *Harsha Kumara* >>> >>> Technical Lead, WSO2 Inc. >>> Mobile: +94775505618 >>> Email: hars...@wso2.coim >>> Blog: harshcreationz.blogspot.com >>> >>> GET INTEGRATION AGILE >>> Integration Agility for Digitally Driven Business >>> >> >> >> -- >> *Samitha Chathuranga* >> *Senior Software Engineer*, *WSO2 Inc.* >> lean.enterprise.middleware >> Mobile: +94715123761 >> >> [image: http://wso2.com/signature] <http://wso2.com/signature> >> > > > -- > *Samitha Chathuranga* > *Senior Software Engineer*, *WSO2 Inc.* > lean.enterprise.middleware > Mobile: +94715123761 > > [image: http://wso2.com/signature] <http://wso2.com/signature> > -- *Samitha Chathuranga* *Senior Software Engineer*, *WSO2 Inc.* lean.enterprise.middleware Mobile: +94715123761 [image: http://wso2.com/signature] <http://wso2.com/signature>
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
