...
AS page api is constructed with list of sections. So before creating page user need to first create sections and then associate those sections with page.
- As of now all page api is public , so without any key it can be access, that can have potential security issues.
- Most of the time user is doing section settings with invalid data type and that will cause page api issues.
- Number of sections inside page has no limits, So if user has set too many sections then it won't work as expected.
- As of now System can make section call to Content search only or only one end point but there might be scenarios where we need different sections data end to be collected from different endpoints.
Proposed Solution 1:
We can divide page api in two category one for public access and another for private access(only after login). So during page creation user need to indicate it.
| Public | Private |
|---|---|
| Number of section can be very small. Ex: Max 3 sections allowed | Number of sections can be configured little more |
| On public access, we can avoid filter options | private page will have all filters and other options |
| Public page response can be catch with some ttl |
Changes Required.
1. in page_management table need to add one column "visibility" with value as {"public" or "private"}
2. Section validation will happen during create/update page based on visibility.
3. Authentication will be checked conditionally. Means if it's public then authentication not required but for private it's required.
Proposed Solution 2:
Define a separate end point for public page access.
| Pros | Cons |
|---|---|
| no impact on existing api's | need to manage one more endpoint |
| Reduce testing effort | |
| All changes regarding public access will be handle separately |
Problem Statement 2:
Proposed Solution 1:
During section create or update time , system will do the section data type validation, in case section query is not valid then it won't allow to create it.
...
| Pros | Cons |
|---|---|
| System will have only valid sections | |
| it's a preventive action |
Proposed Solution 2:
System Will do section validation during page assemble api call, if section is wrongly configured then it will throw proper error. This scenario is already implemented in release-1.13.
...
| Pros | Cons |
|---|---|
| it's a corrective action | DB will have incorrect section |
Problem Statement
...
3 :
Proposed Solution:
Sunbird can put some configuration for maximum number of sections inside page. This check will happen during page create/update.
env: "sunbird_max_page_section_allowed"
Problem Statement
...
4 :
Proposed Solution:
System will define list of target and during section create or update time user need to set target as well, if user is not defining any target then default target will be applied.
...