By permissions I meant, the role checks against API artifacts that are stored in the APIM DB. We store the allowed roles(the role name as a string) along with the artifact in the DB. These are APIM specific. For example if a user is doing a search for APIs by name and does not have the required role assigned to view a given API in the APIM DB, then that particular API should not be returned in the search results.
Sorry if I caused confusion by using the word permissions, we are only working with roles in this case. Of course the permissions are defined within the role, but we will not be going to that level since that is handled by the user core. And the given users roles will also be obtained from the user core. On 15 November 2016 at 18:44, Manuranga Perera <[email protected]> wrote: > Hi Jayanga, > Doesn't this functionality overlaps with permission checking implemented > for C5? > > On Tue, Nov 15, 2016 at 1:10 PM, Uvindra Dias Jayasinha <[email protected]> > wrote: > >> Pagination is required whenever we return a collection of items to the >> requester and we use widely as part in the REST API. >> >> Initially we thought of supporting pagination at DB level. This ensures >> that only a limited dataset is read at a given time based on the offset and >> limit values provided by the caller. To support this we need to maintain DB >> vendor specific SQL statements since pagination at DB level is >> propitiatory. >> >> But there are a few complications with some of our use cases when relying >> on DB pagination. >> >> 1. Display only the latest version of a given published API by the API >> Store - Since the version is a VARCHAR column we cannot assume it is >> numerical so its not straightforward to find the latest version of a given >> API via SQL. We can overcome this at Java level by implementing a >> sophisticated String comparator. >> >> 2. Validate an APIs roles against a given users roles to validate >> eligibility to view the API - In situations where users have a large number >> of roles assigned to them we will need to pass all these roles in the WHERE >> clause of the SELECT statement when filtering the result set further >> complicating statement. >> >> Given that in the C5 tenancy model each tenant will have there own DB >> instance, data numbers will be quite low. For example it will be unusual to >> have a 1000 APIs in the DB. So in this scenario its a lot easier to read >> the entire result set into memory at the back end and then paginate what is >> returned to the caller at Java level along with doing permission checks. >> the advantage of this is, >> >> 1. Minimise the need to maintain vendor specific SQL for pagination >> >> 2. Simplifies SQL statements >> >> 3. Easier to implement the above use cases in Java >> >> We can minimise database access to read all the information by having a >> local cache with a time out of about 30 seconds which we can use to serve >> requests. When a new API is added it can be added to the cache. >> >> >> -- >> Regards, >> Uvindra >> >> Mobile: 777733962 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > With regards, > *Manu*ranga Perera. > > phone : 071 7 70 20 50 > mail : [email protected] > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Regards, Uvindra Mobile: 777733962
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
