Custom Benefit API Security

[Justin-MacIntosh]

User Story

As a Dev working on Builder API, I would like for API Endpoints related to Custom Benefits 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 Custom Benefit to be removed to avoid Developer confusion.

Acceptance Criteria

• The current POST endpoint for Custom Benefit is updated to only accept the fields name and description. This POST should create a new, blank Custom Benefit with the given name and description (and a corresponding BenefitDetail on the related Screener). It should NOT BE POSSIBLE to create a Custom Benefit that already has values for fields such as checks.
• The current PUT endpoint for Custom Benefitis changed to a PATCH endpoint.
  • This PATCH endpoint is changed to only allow edits to the fields name and description.
• Two new endpoints should be created. One endpoint for adding CheckConfigs to a Custom Benefit, and another for removing a CheckConfig from a Custom Benefit. The endpoint for adding a CheckConfig should only take the id of the EligibilityCheck being referenced, and the values to fill out the CheckConfig should be retrieved by the API logic.
  • This is to avoid giving the API user too much power in defining CheckConfigs. A CheckConfig is supposed to be a snapshot of an EligibilityCheck at the time of adding it to a Benefit. Allowing granular editing of the CheckConfig defeats this purpose and exposes us to malicious behavior.
  • This change will require several UI changes.
• The unused fields isActive and isPublic are removed from the Custom Benefit model.
• Any UI-related changes that are necessary to prevent the above changes from breaking the User Workflow are made.

Notes

• Extra Credit:
  • • Does id need to actually be stored in the firebase document for Custom Benefit, or can this model's id function like Screener?