FORMS-1563: auto-approve new ext api when same ministry/url already a…

[usingtechnology]

…pproved.

Description

Simplify Approving External APIs.
If a Ministry and an Endpoint URL (everything except query string) have already been approved, then new External API configurations for the same Ministry and Endpoint URL can be auto-approved.

On the Admin side, if you approve a Ministry/Endpoint URL for an External API configuration, then update all similar configurations (same Ministry, same endpoint).

This just makes life easier when the same owner/designer creates numerous forms or numerous External API configurations (or both!) that point at the same base API. This will also speed things up for the form owner/designer as they don't have to seek approval and wait.

Type of Change

feat (a new feature)

Checklist

• I have read the CONTRIBUTING doc
• I have checked that unit tests pass locally with my changes
• I have run the npm script lint on the frontend and backend
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)
• I have approval from the product owner for the contribution in this pull request

Further comments

[usingtechnology]

It would be great to deploy this, so we can try it out. Now that we're not.... limited... by k8s limits, we can have a lot more PRs deployed. This is good but also probably a bad thing, because four of the nine deployed PRs are no longer open - but it would be great to automate the undeployment.

Removed 4 "dead" deployments with your help, and have deployed this one. Best way to test is 2 forms with different ministries then add some multiple External APIs with the same base URL to each form and do approvals in the Admin/APIs section. All matching External APIs should be approved after first Admin approval. Then back in the form, add another API with the same base url and it should be auto-approved.

[github-actions]

Release e8324f9 deployed at https://chefs-dev.apps.silver.devops.gov.bc.ca/pr-1543

[WalterMoar]

I don't know if this auto approval is possible. If I was to find out an URL for another ministry's external API, then I could create a form misrepresented as being from that ministry, and with a matching external API. Then I just wait for their external API to get approved and I could then start sending data to their URL from CHEFS.

[WalterMoar]

There is an SQL injection possible with this raw query. It's convoluted, but unknown if/how a bigger problem could be made:

1. Create a form "A"
2. Copy your bearer token and curl in a put request for the form data and set the ministry to ' OR 'x'='x, so that the where clause evaluates to true no matter what the ministry is
3. Create an external API for "A"
4. Create a form "B" in a different ministry and give it the same URL for an external API
5. Approve form A's external API, and form B's external API will be automatically approved.

Hopefully the admin will notice this:

but perhaps there are ways to obscure it.

[usingtechnology]

That would be a bug in form API. And would be a db issue that we have no integrity on that column. So I can "block" that here but that's not where the bugs are. Even worse, Ministry values are frontend only. See: #1188

Adding a bandaid to prevent sql injection in this query, but bugs should be filed and addressed.

[usingtechnology]

I don't know if this auto approval is possible. If I was to find out an URL for another ministry's external API, then I could create a form misrepresented as being from that ministry, and with a matching external API. Then I just wait for their external API to get approved and I could then start sending data to their URL from CHEFS.

External APIs are read-only and should be protected, either with an API Key or by examining the incoming headers (who the user is and from which form) or both.

There are no APPROVED external apis that are not protected with an API Key.

If we only (manually) approve secured APIs then this isn't an issue. And if we (manually) approve insecure APIs, there could be a reason for it (ie. it is a public 3rd party API) and again, isn't an issue.

[usingtechnology]

Added "sendApiKey" to the Admin approval screen. Admins can be assured that any other External API configs will not work without providing a key from the API owner. Or they can get assurance that it is a public API with no restrictions.