VRMS stakeholder meeting, August 2024

[shmonks]

Overview

We are meeting with a key stakeholder, the VRMS team, to discuss their needs and gain input as we continue with initial setup.

This issue records both our questions for them and their responses/feedback.

Action Items

• [x] Set up meeting (Monday August 12th 2024 @ 7pm PST)
• [x] Ask all PD team members for input ahead of meeting
• [x] Gather PD team questions and discuss with VRMS
• [x] Record VRMS responses/feedback in Comment below
• [x] Add related agenda item for discussion in next PD: All meeting

Resources/Instructions

• Issue #35
• PD: Table and Field definitions sheet
• ERD
• Other resources and links

[shmonks]

Questions for VRMS

• [ ] User_status_type table: should description remain in this table's description column - or would it be better to move description to the data dictionary created by Chelsey and not have the description column?

[fyliu]

app token for login

• [ ] can VRMS keep a private app token to use when calling the AWS Cognito login API?

Background info

• Cognito calls it a client_secret password where each API client (VRMS, CTJ, website) should have a different one https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-client-apps.html

[fyliu]

login process

I remember the old v0.4 VRMS got it working to the point where it was able to create new users in the cognito user pool and was able to login to cognito and get a JWT. Basically, it should work like that, where

• VRMS authenticates with cognito first,
• gets the JWT, and
• uses that JWT when requesting data from the peopledepot(PD) backend.

PD backend will be able to recognize the token and know which user is making the request.

Reasoning

• it's like using other single signon services like Google. The idea is you don't necessarily trust the backend enough to send it your actual Google login password.

[shmonks]

APIs for VRMS features

• [ ] What features do VRMS have that we can work on the APIs for?

[Neecolaa]

Potential PD Schema Change: We need to include a way to indicate whether or not a project's github repo is archived. If a project has multiple github repos, each repo can have an archive indicator.

[shmonks]

Notes from meeting

• [ ] VRMS to draw up a list of features for which we can develop APIs, with the specific fields/functionality they need (GitHub issue + link via Slack). This will enable us to prioritize those APIs that match with their Dev priorities. We'll see what they request but some initial ideas from VRMS = Assigning admin level of access so they can onboard developers properly; Adding a new project; Adding an event.
• The preference was to keep description as a table column - see comment.
• Token for login: VRMS has no preference at present for proxy vs browser-level authentication - see comment and comment.
• Project Status labels 1: VRMS have been using both Archived and Closed - they will change to just Closed.
• [ ] We need to indicate whether a project's GitHub repos have been archived - see comment.
• Project Status labels 2: VRMS is currently working on project status = Deleted (held for 90 days before deletion) - we added Deleted label to the Project Status table.
• Events in VRMS: down the line, we'll work with VRMS on restructuring the Events model.

[fyliu]

I'm not sure if VRMS needs to do Cognito client_secret. It came from something Bonnie wanted which is to control what apps can access the peopledepot backend.

So that could be an app token. But app tokens aren't useful if they're available in the frontend where the user can potentially access them if they know what they're doing. That's why there's the backend requirement. But Cognito documentation itself doesn't recommend using client_secret for frontend apps. It recommends having it for apps with backends, like CTJ.

Another way to limit access is to limit the IPs and such that can send API requests. Maybe that route is the way to go if we want to control API access.

Or maybe there are other ways.