feat(Google BigQuery Node): Add parameterized query support

[killthekitten]

Summary

This PR adds a basic support for BigQuery's Parameterized Queries feature. This important feature helps prevent SQL injections that are otherwise widespread in n8n workflows due to wide use of string concatenation.

The implementation is a stripped down subset of what it could be if implemented correctly, and should be treated as a PoC. I'm more than happy to implement a few changes along the way! I've been using the parameterized query implementation from the PostgreSQL node as a reference.

This is my first PR, so I left out documentation and tests until the general direction of implementation is confirmed.

Named parameters vs positional vs both

To specify a named parameter, use the @ character followed by an identifier, such as @param_name. Alternatively, use the placeholder value ? to specify a positional parameter. Note that a query can use positional or named parameters but not both.

For simplicity I decided to only support named parameters. It won't be hard to support both modes, we just need to decide on the UX. Ideally, I'd avoid the solution that the PostgreSQL node uses:

Having to pre-process the input to strip down commas, sanitize and extract the values defeats some of the security benefits that parameterized queries are designed to add in the first place.

Configuration visibility

I decided to hide the named parameters into the option dropdown. This is based on an assumption that not a lot of users would care enough about this feature to bring it to the top level, and this would work have better backwards compatibility (existing nodes won't show the new options unless the user explicitly enables them).

The feature is incompatible with Legacy SQL, so the new inputs will only show up when the "Legacy SQL" toggle is switched off. This can be confusing for people who still use Legacy SQL and would discourage them from using a better secure default, so I would rather look for a different UX solution for disabling this option in legacy mode.

Advanced type descriptors

The BigQuery API enforces strict typing of parameters in parameterized queries. Full support of the BQ type system in this feature is out of question, as this would result in a complex UX. It would be a stretch to support all the various ways the types can be defined, so I decided to only supported the "STRING" type.

This can be improved in a few ways:

Using @google-cloud/bigquery package
If we switch this node to the official JS SDK from Google, we should be able to use the getTypeDescriptorFromValue helper at runtime, which would infer BQ type descriptors of any valid JS value automatically, allowing for complex javascript values.

Manual type definitions
Another, less user-friendly option, would be to allow users to specify the types manually by providing a JSON describing the type:

[
  {
   "parameterType": {
    "type": "STRING"
   },
   "parameterValue": {
    "value": "M"
   },
   "name": "gender"
  },
  {
   "parameterType": {
    "type": "ARRAY",
    "arrayType": {
     "type": "STRING"
    }
   },
   "parameterValue": {
    "arrayValues": [
     {
      "value": "WA"
     },
     {
      "value": "WI"
     },
     {
      "value": "WV"
     },
     {
      "value": "WY"
     }
    ]
   },
   "name": "states"
  }
 ],

SQL Editor autocompletion

Unfortunately, this feature doesn't play well with the SQL editor. It doesn't break the highlighting of the queries, but autocompletion doesn't know about the parameterized value placeholders such as @name. I don't think it's a major blocker, but we could look into it further.

Related Linear tickets, Github issues, and Community forum posts

Review / Merge checklist

• PR title and summary are descriptive. (conventions)
• Docs updated or follow-up ticket created.
• Tests included.
• PR Labeled with release/backport (if the PR is an urgent fix that needs to be backported)

[CLAassistant]

All committers have signed the CLA.

[Joffcom]

Hey @killthekitten,

Thanks for the PR, We have created "GHC-1412" as the internal reference to get this reviewed.

One of us will be in touch if there are any changes needed, in most cases this is normally within a couple of weeks but it depends on the current workload of the team.