@Sanjeewa, if someone edits the Swagger file in conf, how do we ensure the next restart doesn't override that file?
The root cause of the problem here is that the "resource to scope" mapping is both a server configuration as well as it might be a user configuration when users want to find/corse grain the permissions of the API. What if we allow the default resource to scope mapping remain in the Swagger doc and introduce a new config file to override whatever resource to scope mappings a user needs? To determine the scope of a particular resource our code should first be checking the custom/optional config file and if an entry for the particular resource doesn't exist, then default to the Swagger file. This way the optional config file only needs to bear the resource to scope mappings that need to be overridden in a particular deployment and hence won't be that long. It also ensures that during product upgrades users don't have to meddle with the current config file and can keep using it on newer versions too. Thanks, NuwanD. On Mon, May 8, 2017 at 11:46 PM, Sanjeewa Malalgoda <[email protected]> wrote: > > > On Mon, May 8, 2017 at 3:42 PM, Ishara Cooray <[email protected]> wrote: > >> >> >> *Motivation:* >> Before c5, API Manager product REST APIs resources have pre defined >> scopes and they cannot be changed. >> >> But what if an admin needs to give access to Create, Update, Delete >> actions to different users? >> if he can customize the scopes associated with each resource, then he >> will be able to fine grain the access to each resource. >> >> >> >> *Design:*With C5, we thought of allowing admin users to add/change >> scopes in product REST APIs to meet their fine grained requirements. >> >> At the moment we can think of two ways to do this. >> >> 1. *Allow to edit the scopes defined per resource * >> In this case we can copy the swagger file into conf directory at >> build time, so that it can be maintained as a usual configuration file. >> >> When server startup we can copy these swagger files to conf directory and > refer it from there. Maintain separate file for mapping make things more > complex IMO. > Lets follow this for all swagger based APIs. > > Thanks, > sanjeewa. > >> >> 1. >> 2. *Introduce a new config file to track resource to scope mapping.* >> In this case the issue is resource to scope mapping will be >> duplicated. >> >> Appreciate your insight on this. >> >> >> Thanks & Regards, >> Ishara Cooray >> Senior Software Engineer >> Mobile : +9477 262 9512 <+94%2077%20262%209512> >> WSO2, Inc. | http://wso2.com/ >> Lean . Enterprise . Middleware >> > > > > -- > > *Sanjeewa Malalgoda* > WSO2 Inc. > Mobile : +94713068779 <+94%2071%20306%208779> > > <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda. > blogspot.com/ <http://sanjeewamalalgoda.blogspot.com/> > > > -- Nuwan Dias Software Architect - WSO2, Inc. http://wso2.com email : [email protected] Phone : +94 777 775 729
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
