Sprint #1 - Daily Scrum #09

Product: CMS API
Sprint Summary

Daily Objectives

• Make sure the website is updated
• Make sure the next sprint is planned

Notes

Let’s hecking finish this mother hecker
Data Design cont.

Resources:

1. Project
2. ProjectPages
   • A Page object that holds a series of PageEntries (page entries are unrelated to each other)
3. ProjectCollections
   • A Collection object that holds multiple Collection Entries
4. CollectionEntry
   • An instance for a ProjectCollection
5. PageEntry
   • An instance in a ProjectPage
6. EntryItem
   • Ex: H1 Header, P Item, Media Item
   • Will have a ‘Type Field’ and a ‘Content Field’
     • Or make a resource object for each type of available object?
     • We can define two general content types:
       • Text Content
       • List Content
       • Article Content(?)
7. MediaUpload
   • Checking if necessary

Each Collection Entry requires a specific schema/order of EntryItems, but some EntryItems such as ‘ArticleType’ (tentative name), can be content be a linked list of more EntryItems, so there’s expandable content.
The content for a ‘ListType’ can also be a linked list of more EntryItems (but possibly of the same types, but also doesn’t have to)

For Bookshelf.js, It follows the same ‘standard’ Model and Associations. Things to note: you can add functions to fire based on events happening with the db (like onchange, initialization, etc.). There’s also parse and format functions for turning items objects into the correct types (like json strings to lists and whatnot)

Let’s also quickly go over the User/Role Management Service:
Generic options:

1. Create Role Model and attach them to User Models
   • Might require making too many roles if you want more granularity
2. Create Permissions ‘dictionaries’ a field for User’s which define what they can (or can’t do)
3. Have Projects have a list of User’s for certain roles (one to many from project to User)

It might help to do at least a bit of research of best/recommended practices Oh, we can have role relationships between a user and each project. Each project will own multiple roles.

Authorization Models:

1. Access Control List (ACL)
2. Discretionary Access Control (DAC)
3. Mandatory Access Control (MAC)
4. Role-Based Action Control (RBAC)
   • Subject, Role, Permission, Operation
5. Attribute-Based Action Control (ABAC)
   Lmao I’ll probably go with RBAC for uh reasons

Subject(Users)

• Contains list of Role’s
• If doesn’t contain a role for a project, assume no permissions

Role

• …

Permission

• List of operations granted on project/resource?

Operation

• Read/Write on Resource
• Object/Action

BUT, if I want to create a new ProjectPage, do I have to go through all the roles and add operations for everything? We can just add a prompt to the ‘Create New Project Page’ to add new permissions for existing roles (include drawing later)

What are the resources?
Pages, Collections, Entries, EntryItems, MediaUploads

OK! Let’s outline the Software Design Document!

Let’s start with the Design Document now! First the TOC/Outline

“SDD usually contains the following information”

1. Data Design
2. Architecture Design
3. Interface Design
4. Procedural Design
   • Which is now commonly replaced by Object Oriented Programming and Design Patterns
   • Is there anything specific I should talk about here?

I think I want to briefly discuss how ‘authentication’ with the database will work? I’ve decided to use the REST API to modify data on the database from the Admin WebUI. This stays a little more true to the whole microservices paradigm, since the Admin WebUI will be accessing both the Content Management and User Roles Management services separately.
A big concern is where authentication will take place:

1. The AdminUI will check first with the Role Management for permissions before making calls to the REST API to modify content. The REST API will only allow requests from the AdminUI for modifying content.
2. The AdminUI will make the call to the REST API, passing along the USER currently logged in, and the REST API will use the Role Management to verify permissions.
   • Other Options suggest to handle authorization at the API Gateway; other people call it an Authorization Interceptor
   • Since I’m essentially using an API Gateway, I think I should definitely follow this model

• How does the Resource Server validate the Auth Token though? An issue with this is that the project requires some sort of ‘in memory’ database
• OH, you’re just using the User/Role Server to verify login information, but you manage the actual sessions in the actual API Gateway!!!!!!!!
• Session Based and Token Based are two different authentication systems
• I’m going to be using Express-Session

Design Document Table of Contents/Overview:

1. Data Design
2. Architecture Design
3. Interface Design
4. OOP/Design Patterns
   • Probably Irrelevant? Maybe talk about the API’s?
   • Maybe figure out how the AdminUI will work, especially before committing changes to the database

Objectives Completed

• defined what the API resources will be

• investigated and decided on creating an RBAC system for user permissions

Lessons Learned

• hey

Plans for Tomorrow

• hey