Disabling introspection with useDisableIntrospection plays badly with validationCache

[lenolib]

In production we disable introspection but allow it on a per-query basis if a special token is supplied in a header.

validationCache: true, 
plugins: [
  useDisableIntrospection({
    disableIf: ({ context }) => {
      const token = context.request.get('introspection-token')
      return token !== process.env.INTROSPECTION_TOKEN
    }
  })
]

If using validation cache, this check becomes useless since the cache seems to cache the first response (either valid or invalid depending on if the correct header value was supplied).

Is there another way to implement this behaviour, or could this potentially be regarded as a bug? It would seem the disable check needs to happen before the validation phase.

(This is a similar "introspection-behind-key" use-case I found: parse-community/parse-server#7972)

[n1ru4l]

This is interesting, I guess we need a way of incorporating the enabled rules of the introspection (or maybe just the header) into a cache key. 🤔

@ardatan Any ideas?

[ardatan]

We can accept a cache key factory to validationCache and document this use case. @n1ru4l ?