Handle Bad Encryption IDs

[dtgreiner]

Merging this PR

• use the squash-merge strategy for PRs targeting a release-X branch
• use a merge-commit or rebase strategy for PRs targeting the stable branch

Description

Handle bad encrypted id values by allowing the controllers to respond as if a record with a matching value was not found (404) instead of throwing an OpenSSL::Cipher::CipherError as that could be confusing to users.

The cipher error is still sent to Sentry.

Type of change

Bug fix

Checklist before requesting review

• I have performed a self-review of my code
• I have run the code that is being changed under ideal conditions, and it doesn't fail
• If adding a new endpoint / exposing data in a new way, I have:
  • ensured the API can't leak data from other data sources
  • ensured this does not introduce N+1s
  • ensured permissions and visibility checks are performed in the right places
• Any major architectural changes are supported by an approved ADR (Architectural Decision Record)
• I have updated the documentation (or not applicable)
• I have added spec tests (or not applicable)
• I have provided testing instructions in this PR or the related issue (or not applicable)

//: # NOTE: system tests may fail if there is no branch on the hmis-frontend that matches the Source or Target branch of this PR. This is expected

[eanders]

That looks good to me, thank you!

[eanders]

Should this raise a NotFound error if the value and params[key] match? Or where is that handled?

[dtgreiner]

That should be the same as if the PROTECTED_IDS setting is not being used and an invalid key is passed. Unless the controller is specifically handling it differently (e.g. client controller) , it should be throwing an ActiveRecord::RecordNotFound error on the controller which responds as a 404.

Example from local environment for Data Source Controller.

Non dev environments should show the 404 page.

[eanders]

Thanks! Just wanted to make sure.