ubclaunchpad / starport Goto Github PK

Acceptance Criteria

• use the middleware function created from this issue: #38
• add the middleware function to call

new LambdaBuilder(router)
    .use(new ScopeController(db))
    .build();

• different scopes should be able to complete different tasks

Development tasks

• work in file: src/roles/deleteUser.ts
• for different scopes add the handling needed

Learning Opportunities

• adding on top of an pre-existing HTTP method

A layer to authorize incoming API requests. The middleware should allow arguments to retrieve the scopes of access.
This will be used by all api endpoints and should be flexible enough to adapt to new changes.

• Create a scope table to store all available scopes. initial setup should be added as migration script

  • Current version of Scopes: Update as needed

  • Convention: [area]:[permission]:[domain]:[limits]

Note: admin:write is a special role we will use to authorize api calls that modify our system such as adding more roles, more scopes and etc. Later on we can assign domains to admins levels such as "members" or "posting"

• Create a role_scope table that has keys to a role's id (from role table) and scope's id (from scope table)

• Middleware should allow to use cases:

• pass user id and authorization and return all scopes of user

• pass user id and authorization with a list of scopes to determine if user has those

Example Scenario

For the Users API:

• Creating Users: only authenticate their google credentials. will want to know if user is authenticated
• Editing Users: Triggered by either user or "admin" roles. will want to know if current user can update either themselves or others
• Delete users: similar to above
• Admin-related: using the api to add a new faculty, role, or remove a program, etc

• User Auth to allow api access to users API
• in addition to users
• #22
• #21
• #20
• #19
• related to #11

Acceptance Criteria

• use the middleware function created from this issue: #38
• add the middleware function to call

new LambdaBuilder(router)
    .use(new ScopeController(db))
    .build();

• different scopes should be able to complete different tasks

Development tasks

• work in file: src/roles/getUser.ts
• for different scopes add the handling needed

Learning Opportunities

• adding on top of an pre-existing HTTP method

• Add all endpoints for role specific tables

• Add all endpoints for pronoun table

• Add all endpoints for standings table

Acceptance Criteria

• takes all updated fields for a profile
  • see database schema for person table
• Able to make a postman call to the endpoint and update an existing user stored in the database with the correct info
• Throws an error if the user does not currently exist in the table

Development tasks

• retrieve all info from the HTTP body
• update the database
• send back the database-generated User ID and all profile info

Learning Opportunities

• Making an HTTP PUT endpoint
• How to update the database row

/specializations/

• GET specializations
• PATCH specialization: update a current standing's name
• DELETE specialization: delete a current specialization:
  • should have a specialization transfer for users whose standings are the to-be-delete one

Related to #11

• Authorization middleware will introduce scopes with roles. only specific scopes should allow to modify and delete specializations. Refer to the issue.

Acceptance Criteria

• use the middleware function created from this issue: #38
• add the middleware function to call

new LambdaBuilder(router)
    .use(new ScopeController(db))
    .build();

• different scopes should be able to complete different tasks

Development tasks

• work in file: src/roles/editUser.ts
• for different scopes add the handling needed

Learning Opportunities

• adding on top of an pre-existing HTTP method

• Add all endpoints for faculty table

Acceptance Criteria

• skips if users exist when creating a user
• add the middleware function to all calls

new LambdaBuilder(router)
    .use(new Authorizer())
    .build();

Development tasks

• work in file: src/util/middleware/authorizer.ts

Learning Opportunities

• creating a middleware function for a lambda

The users API already is capable of creating, deleting, updating, and getting a user. (Albeit not bug-free)

However, as an effort to make the hub a general offering for other teams apart from Launch Pad, they need to accommodate that. This is a research/POC concept that requires some knowledge of how APIs are/should be configured + able to conduct some research on what an organization wants in their member attributes.

• Add all endpoints for ethnicity table

Acceptance Criteria

• Add a middleware function that reads users' role and assigns the scopes in an array style so they can be used accordingly for the API endpoints
• Access Scopes:

ADMIN_READ: 'read:admin',
READ_ALL_PROFILE_DATA: 'read:profile:all',
READ_OWN_PROFILE: 'read:profile:personal',
READ_RESTRICTED_PROFILE_DATA: 'read:profile:restricted',
ADMIN_WRITE: 'write:admin',
WRITE_PROFILE: 'write:profile',
ADMIN_UPDATE: 'update:admin',
UPDATE_ALL_PROFILE: 'update:profile:all',
UPDATE_OWN_PROFILE: 'update:profile:personal',
ADMIN_DELETE: 'delete:admin',
DELETE_ALL_PROFILE: 'delete:profile:all',
DELETE_OWN_PROFILE: 'delete:profile:personal'

Development tasks

• work in the file: src/util/middleware/scopeHandler.ts
• retrieve the scopes related to the user based on their role and the scopes related to that role

Learning Opportunities

• make a lambda middleware function
• make a complex SQL statement with JOINs and multiple tables

/roles/

• GET roles
• PATCH role: update a current role's name
• DELTE role: delete a current role:
  • should have a role transfer for users whose role are the to-be-delete one
  • should have safe-checks for critical roles such as admin

Related to #11

• Authorization middleware will introduce scopes with roles. only specific scopes should allow to modify and delete roles. Refer to the issue.
• Needs to be able to add scopes to and remove from a role: /roles/id/scopes POST to add

THe User's api is already a developed endpoint. with changes coming to the scope of the project in the coming week, we want to go over all anticipated cases we need and create an api contract that we can use for our development and teams that work in parallel to us.

THis is a foundational task and requires more than one person to work on it and at least one developer with api development experience

CRUD API features for users

• Create a member
• Delete a member
• Edit a member
• Get member or members

Acceptance Criteria

• Make the middleware take the handler function (a Promise that resolves or rejects) for each API endpoint that is run and handled accordingly in the middleware
• Add to each endpoint:

new LambdaBuilder(router)
    .use(new InputValidator())
    .build();

Development tasks

• Do research on best input validation for different HTTP Verb types
• work in file: src/util/middleware/inputValidator.ts

Learning Opportunities

• creating a middleware function for a lambda

Unit tests for users api

Acceptance Criteria

getUser

• Correct URL schematics for retrieving a user (e.g /user/{userId})
• Retrieve all info of specific user from the database (JSON object)

getUsers

• Retrieve all info for all users from the database (array of JSON objects)

  • only need to return certain info for each user
    • decide which info is necessary to view on the table of the home page
      • name
      • role
      • email
      • status?

• Make a Postman request for both and get the correct info

Development tasks

• Retrieve info from the database
• send back the database-generated User ID and all profile info

Learning Opportunities

• Making an HTTP GET endpoint
• How to retrieve info from a database

When a new migration script runs, if one of the queries is flawed previous queries are not rolled back.

CRUD API features for Postings

• Create a posting
• Delete a posting
• Edit a posting
• Get postings

AWS DBs are too pricey.

Look into

• CockroachDB

/standings/

• GET standings
• PATCH standing: update a current standing's name
• DELTEE standing: delete a current standing:
  • should have a standing transfer for users whose standings are the to-be-delete one

Related to #11

• Authorization middleware will introduce scopes with roles. only specific scopes should allow to modify and delete standings. Refer to the issue.

Acceptance Criteria

• add all different handling of getUsers listed in the title
• add paramters properly to the URL (e.g. use search query parameters)
• add the middleware function to call

new LambdaBuilder(router)
    .use(new PaginationHelper({ limit: DEFAULT_LIMIT, offset: DEFAULT_OFFSET}))
    .build();

Development tasks

• work on paging similar to how it is set up in src/standings/getStandings.ts
• searching
  • do research on what is the best way to do this
  • maybe just using DB call LIKE or using index searching
• add filtering on different values

Learning Opportunities

• adding on top of pre-built HTTP Methods

Acceptance Criteria

• Correct URL schematics for retrieving a user (e.g /user/{userId})
• Make a Postman request and remove the user from the database

Development tasks

• Call to delete row from the database
• send back a success or error message depending

Learning Opportunities

• Making an HTTP DELETE endpoint
• How to delete info from a database

• Aurora Serverless Stack for db
  • Db initialization
• API stacks
  • improve automation
  • better local api testing
• Testing setup
• Deployment scripts

Acceptance Criteria

• takes in all necessary data
  • see database schema for person table
• Able to make a postman call to the endpoint and create a new user stored in the database with the correct info
• If an error occurs ensure it does not write anything to the database

Development tasks

• retrieve all info from the HTTP body
• write it to the database
• send back the database-generated User ID and all profile info

Learning Opportunities

• Making an HTTP POST endpoint
• How to write to the database

CRUD API features for Projects

• Create a project
• Delete a project
• Edit a project
• Get project(s)

The USER API's GET endpoints retrieve everything for a user. We do want to have those information but we should split certain information to speed up fetch times.

currently GET USER will have the following example response:

{
    "id": 1111,
    "username": "jake",
    "email": "[email protected]",
    "firstName": "jake",
    "prefName": "jaketheman",
    "lastName": "jakeson",
    "resumeLink": "jake.com",
    "createdAt": "2023-06-20T07:27:19.000Z",
    "updatedAt": "2023-06-21T06:14:46.000Z",
    "memberSince": null,
    "faculty": {
        "id": 3,
        "name": "Education"
    },
    "standing": {
        "id": 4,
        "name": "Fourth Year and up"
    },
    "specialization": {
        "id": 3,
        "name": "American Studies"
    },
    "roles": [
        {
            "id": 1,
            "name": "Explorer"
        }
    ]
}

Augment the GET users/{id} to accept query parameters to select only relevant information:

• create a default to query string passed to only return:

{
    "id": 1111,
    "username": "jake",
    "email": "[email protected]",
    "prefName": "jaketheman",
    "memberSince": null
}

• users/{id}: to accept query string parameters to determine what to fetch.
  • string params should also allow for shorthands to avoid long URIs:
    • meta: information related to account:

{
   "id": 1111,
   "username": "jake",
   "email": "[email protected]",
   "firstName": "jake",
   "prefName": "jaketheman",
   "lastName": "jakeson",
   "resumeLink": "jake.com",
   "createdAt": "2023-06-20T07:27:19.000Z",
   "updatedAt": "2023-06-21T06:14:46.000Z",
   "memberSince": null
}

• Add users/{id}/roles GET to fetch user roles

• Add all endpoints for gender table

/faculties/

• GET faculties
• PATCH standing: update a current faculty's name
• DELTEE standing: delete a current faculty:
  • should have a faculty transfer for users whose faculties are the to-be-delete one

Related to #11

• Authorization middleware will introduce scopes with roles. only specific scopes should allow to modify and delete faculties. Refer to the issue.

Object key should accept either area or doc and both.

Extra layer for github id is needed before the object key.

This task is based around research of potential users' needs. As an example LP needs basic information from its new members, resumes, etc; this might vary between different teams/clubs. For this task you should brainstorm on your own, from your own experience, inspo, asking around, etc to see what other scenarios would require different type of information and how we can offer that.

Acceptance Criteria

• Authentication needs (Is google enough or more should be offered)
• Do we need to include "dynamic" fields each team can choose on their own?
• What are the essential fields to include
• Access scope is also a major thing which we plan to address how do others see this
• How important are integrations and what integrations are desired.

• Add all endpoints for specializations table