fix(next-drupual): optional authentication to get access token

[Arijeet996]

This pull request is for: (mark with an "x")

• examples/*
• modules/next
• packages/next-drupal
• starters/basic-starter
• starters/graphql-starter
• Other

GitHub Issue: #667
Please add a link to the GitHub issue
where this problem is discussed.

• I need help adding tests. (mark with an "x")
  Code changes need test coverage. If you don't know
  how to make tests, check this box to ask for help.

Describe your changes

Modified code for getAccessToken function to throw an error if clientId and clientSecret are not present in both default and optional parameters.

[vercel]

@Arijeet996 is attempting to deploy a commit to the Chapter Three Team on Vercel.

A member of the Team first needs to authorize it.

[JohnAlbin]

First: good catch! This is definitely buggy and needs fixing.

Looking at this closer, I can see that the underlying problem is that isBasicAuth() and isClientIdSecretAuth() are both implemented incorrectly. They are currently implemented to detect if some of the related auth properties are present in the auth object, but they don't guarantee that the auth is valid.

Looking at the code, it's clear that those functions are supposed to verify the auth object has valid credential properties:

function isClientIdSecretAuth(
  auth: DrupalClient["auth"]
): auth is DrupalClientAuthClientIdSecret {
  return (
    (auth as DrupalClientAuthClientIdSecret)?.clientId !== undefined ||
    (auth as DrupalClientAuthClientIdSecret)?.clientSecret !== undefined
  )
}

The name of the function is literally isClientIdSecretAuth implying that it is verifying that the auth is a valid pair of id/secret properties.

More importantly, you can see the return type of isClientIdSecretAuth() is auth is DrupalClientAuthClientIdSecret, a boolean indicated that the provided auth: DrupalClient["auth"] parameter is actually a DrupalClientAuthClientIdSecret. The function is designed to let TypeScript know that the parameter has been verified to be a particular Type.

The problem is that isClientIdSecretAuth({ clientId: 'some-id' }) and isClientIdSecretAuth({ clientSecret: {} }) both return true. BUT, in order for auth to be valid it must match this type definition:

export interface DrupalClientAuthClientIdSecret {
  clientId: string
  clientSecret: string
  url?: string
  scope?: string
}

And you can see that both clientId and clientSecret are required strings. And that's not what the body of the function checks. :(

When we fix isBasicAuth() and isClientIdSecretAuth() it will break set auth because its logic is dependent on the incorrect logic of the existing (buggy) implementation.

[JohnAlbin]

The fix needed is more complicated than this PR provides. Since its related to some Jest tests that are skipped that I just wrote, I'll see if I can find some time to tackle it if no one gets to it before me.