Page Comparison

Implementation design call on 19th July 9-10:30 am

Attended by - Rayulu, Mahesh, Kartheek, Kamesh, Bharat, Aayush, Saket

(Capturing all the details from the call here)

Phase 1 - Allow creation of Private content + Searching and Reading of Private content

Phase 2 - Allow conversion of Private content to Public Content

In 4.2 - These 2 phases will be done

Phase 3 - Allow conversion of Public content to be Private <Use case for this needs to be defined, before considering development>

Resource needed - Java Scala

Public Search API

Meeting - 1

Consumption Repo

Search API

There will be two sets of search and Read API on the consumption repo:

• Public Search API (Existing) to provide public content only.

• Private Search API (new) to provide Private as well as public content

Public Search API - (Existing, Changes needed)

1. At present, if a specific request is made for the private content through API. the private data is also returned. This behavior needs to be updated.
   Going forward only Public content should be returned In the current behavior, it also returns private content, if specifically asked for it. One change that needs to be done is to limit this behavior to stop returning Private content and only
   (Change) - Not allow private content to be returned. Only public content should be returned.

Private Search API

...

(New)

1. (New) New API to be created

   1. An exact replica of the public

   search API. with the relaxation of returning Private + Public content.

2. Restricting private content access:

   1. API Token-based access, to call the Private APIs, API tokens will be needed.

3. Restricting content within the organization/tenant

   1. User token is also needed along with API token while making the API call - Based on User’s organization/channel private data will be shared

   2. In the case of external apps calling the private API → The API token can be linked to a channel

4. When a private API call is made

   1. User token is checked for org/channel

   2. Channel details if added by Kong is checked (based on API token)

   3. If the channel is not found → then the access is restricted as unauthorized access

...

1. 1. Search API

   2. One relaxation from the public search API - This should return both Public & private content

   3. Will work only on API Token-based authentication

   4. The API token will be linked to a tenant - Only content of that tenant is returned

2. Restricting access

   1. Private content access

      1. Only share content via Private Search API

      2. API must be called with a token

   2. Tenant level restriction - only content related to the tenant is shared

      1. The API token is linked to a tenant

      2. User (if registered on Diksha) sends User Token as well as the API token - Tenant is recognized based on 1st user token, 2nd API token, then the access is given to private content

      3. In absence of tenant details, API token the access is marked as unauthorized acees

(Similar implementation - tenant linked to API token, is already done for Data Exhaust)

Complexity:

1. The above approach restricts the searching and accessing of content only within the tenant organization and not across organizations.
   For example - there is a question creation organization called Akshara which creates questions/ question papers. How can they get access to the private content?

2. How will be the behavior for the Sourcing - Since there is no channel defined for the content till it is published

Read API behavior:

Read → Shows last published content only, if not published returns no value

...

Read API

Exactly the same as the search APIs, there will be two sets of API on the consumption repo:

1. Public Read API (Existing) to provide public content only.

2. Private Read API (new) to provide Private as well as public content

Public Read API - (Existing, Changes needed)

1. (Change) Restrict returning of any private content, even when specifically asked in API call. At present, private content is also returned. (Same change as public search API)

Private Read API

1. (New) New API to be created

   1. Replica of public read API

   2. (Change) This API is allowed to return private as well as public content

   3. The API token is a must while calling this API

   4. API token - linked to a tenant - Only content of that tenant should be returned

2. Restricting access

   1. Private content access

      1. Only share content via private read API

      2. API must be called with a token

   2. Tenant level restriction

      1. The API token is linked to a tenant

      2. Only content related to that tenant is allowed

Sourcing repo

4.2 Development

1. Search and Read API will provide both private and public content to the contributor

   1. (Change) need to check the current behaviour of API and allow all (private, public) content

2. Through Frontend flows - Access will be restricted to only contributors and reviewers

3. If a specific API call is made it would return both the private and the public assets

4. APIs will be accessed based on API token

In 4.3 or beyond

1. We need solve for the situation where external restriction can be made to access private and public content based via APIs as well.