Screener API Security

[Justin-MacIntosh]

User Story

As a Dev working on Builder API, I would like for API Endpoints related to Screeners to only be able to edit the pieces of data they need to edit in order for the backend to function properly, so that no potential vulnerabilities exist when hitting the Builder Web API directly. I would also like any unused fields on Screener to be removed to avoid Developer confusion.

Acceptance Criteria

• The current POST endpoint for Screener is updated to only accept the field screenerName. This POST should create a new, blank Screener with the given name. It should NOT BE POSSIBLE to create a Screener that already has values for fields such as publishedScreenerId or benefits.
• The current PUT endpoint for Screener is changed to a PATCH endpoint.
  • This Patch endpoint is changed to only allow edits to the fields screenerName and formSchema.
• The unused fields organizationName and resultsSchema are removed from the Screener model.
• Any UI-related changes that are necessary to prevent the above changes from breaking the User Workflow are made.

Notes

• For extra credit here, determine if there is a way to tag or denote id as a read-only field for the Screener model. Currently the id is the automatically generated Document ID of the record in firebase, and is not a field within that document.

[joshwanf]

@Justin-MacIntosh Check out db4a75a as a proof-of-concept commit.

Create a screener requests must exactly match the CreateScreenerRequest DTO (must include all required fields, may not contain extra fields). The request body is serialized by Jackson and used in the Screener.create() constructor. The flow to Firestore is unchanged after that.

• POST /api/screener expects the CreateScreenerRequest DTO.
• Supplying extra fields triggers an application-wide UnknownFieldException. This will cause other endpoints to return an error, so we must decide whether we like this behavior to be standardized.
• Supplying too few fields triggers Quarkus bean validation and returns the default error message for now (I will probably add a ValidationExceptionMapper in to match UnknownFieldExceptionMapper).

I tested the responses using Postman, and if we like it, we can do one of the following:

1. Keep the response shapes as it.

2. Type guard the response shapes for the frontend so that it expects the following:

   type CreateScreenerResponse = 
   | { error: true; message: string }
   | { success: true; screener: Screener }