AN-614: Allowed security scheme must exist in config.json

[acenolaza]

AN-614: used zod.superRefine() in order to validate that the security scheme enabled under ois.apiSpecifications.security is defined in ois.apiSpecifications.components.

[Siegrift]

👍 LGTM.

I think we should also verify that the the security scheme value is set via the apiCredentials https://docs.api3.org/airnode/v0.6/grp-providers/guides/build-an-airnode/api-security.html#step-3-specify-the-values-for-the-defined-security-schemes but we can do that as a separate issue? WDYT?

[acenolaza]

+1 LGTM.

I think we should also verify that the the security scheme value is set via the apiCredentials https://docs.api3.org/airnode/v0.6/grp-providers/guides/build-an-airnode/api-security.html#step-3-specify-the-values-for-the-defined-security-schemes but we can do that as a separate issue? WDYT?

Right, I thought about doing that at first but then I realized that securityScheme is optional in apiCredentials but maybe I could still do a one-way check (if apiCredentials.securitySchemeName is defined then check if ois.apiSpecifications.components.securitySchemeName is also defined. WDYT?

[Siegrift]

Mhh, actually maybe we can bring this up at the call. I can imagine an user taking full OAS of their API, making a few changes to convert it to OIS and enable only a subset of triggers and security schemes. That suggests we should not do this check and allow "unused" security schemes. But for other users this will be an annoying error they'll need to debug 🤷 .

However, for enabled security schemes (via the security field) we need make sure that the value is defined in apiCredentials.

[acenolaza]

Mhh, actually maybe we can bring this up at the call. I can imagine an user taking full OAS of their API, making a few changes to convert it to OIS and enable only a subset of triggers and security schemes. That suggests we should not do this check and allow "unused" security schemes. But for other users this will be an annoying error they'll need to debug shrug .

Yes, and this has been how I've been approaching "reference" validation in Airkeeper and Airkeeper. For those config files I'm only adding checks for things being referenced but unused things are not being validated for convenience since having those config values there don't really hurt and makes testing easier when switching between config values.

However, for enabled security schemes (via the security field) we need make sure that the value is defined in apiCredentials.

The thing is that we only care about apiCredentials.securitySchemeValue being set when securityScheme.type is apiKey or http 🤔

[Siegrift]

The thing is that we only care about apiCredentials.securitySchemeValue being set when securityScheme.type is apiKey or http 🤔

No. I mean when you have a security scheme that is defined and also enabled. Such as this then we should verify the value is also supplied in apiCredentials (here). Essentially, making sure that user defined the step 3 from the docs.

[acenolaza]

The thing is that we only care about apiCredentials.securitySchemeValue being set when securityScheme.type is apiKey or http thinking

No. I mean when you have a security scheme that is defined and also enabled. Such as this then we should verify the value is also supplied in apiCredentials (here). Essentially, making sure that user defined the step 3 from the docs.

But what if the Airnode is only relaying metadata using securitySchemes? https://docs.api3.org/airnode/v0.4/grp-providers/guides/build-an-airnode/api-security.html#relayed-meta-data-security-schemes

[Siegrift]

Oh, I see what you mean now. Yes, we only care about those two. But if they are defined and used, there should be a value defined for them in apiCredentials

[acenolaza]

Thanks for the thorough and detailed code review @Siegrift 🙏🏻

[Siegrift]

👍 LGTM