Elisa/7492 public device endpoint

[emyl3]

BACKEND PULL REQUEST

Related Issue

• Part II of Demo/Training: Update Device List to Match Production #7492

Changes Proposed

• Add a public endpoint /devices that returns all DeviceTypes (without any internal ids)
  • leverage @JsonView annotation to return certain fields
  • protect the endpoint by ensuring the request to that endpoint has a custom header Sr-Prod-Devices-Token with the valid token (See Add prod device sync related secrets to tf configs #8323 for how to get the token value)

Additional Information

• co-authored by @DanielSass
• created a new DeviceTypeProdSyncService for logic related to the device sync from prod
  • TBD I may or may not combine this with the existing DeviceTypeSyncService or just rename this service to make it clear it is for the LIVD sync will depend on how the sync is implemented in part III

Testing

• deployed on dev4
• use an API testing tool of your choice to fetch the device list from dev4
  e.g.

  curl --header "Sr-Prod-Devices-Token: REPLACE_TOKEN_HERE" https://dev4.simplereport.gov/api/devices
  

  • you should see the entire list without any InternalIds
• use an API testing tool of your choice to hit that same endpoint without the Sr-Prod-Devices-Token header
  e.g.

  curl -v  https://dev4.simplereport.gov/api/devices
  

  • you should see no devices and see that the request is Unauthorized

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[bobbywells52]

Tested and the end point works as expected with and without authorization + paired with Elisa and talked through all of my questions -- LGTM! Thanks for all of you work on this Elisa!!

[mpbrown]

Tested the endpoint and everything looks good!

With the current configuration it looks like the lower environments will also end up having this endpoint active right? Just want to check whether that is desired or whether we should have a configuration setting so that by default the endpoint is disabled in the lowers but could be turned on for testing if needed similar to the sendgrid config setting?

[DanielSass]

@emyl3 Have you looked into our concerns that removing these ignore tags will cause an issue?

[DanielSass]

And I apologize because I just now realized I never added that detail to the ticket:

#7492 (comment)

[emyl3]

I had previously deployed this branch both with and without the @JsonIgnore -- is this what you were thinking in terms of adding a timer and logging to see if there's a difference with and without the @JsonIgnore

This is with the JsonIgnore tag

This is without

[emyl3]

Let me know if this is not what you had in mind and I can adjust the testing plan and retest 😅

[DanielSass]

Part of me thinks that the issue is no longer relevant because the audit log was moved out of our db table. The other part of me thinks if it is somehow still an issue, we aren't going to see it until we send this to prod.

[DanielSass]

I talked to @mehansen about this a bit and I loved her idea of just trying to replicate the original issue as a means of confirming that its no longer a concern. But again, the lack of an audit log in the db might make that a futile effort.