Oauth2 tokenPrefix can't be empty

Developers Central
1

I can’t set the authentication header prefix to be “empty” or “nothing” or “null”. Setting to an empty string forces the default prefix of "Bearer ", and setting to null throws an error during compile. Omitting the parameter again sets the value to the default "Bearer ".

AWS Cognito default Authorizer isn’t set up to handle a token being passed with any kind of prefix. So, to get around this, I will have to create a custom lambda authorizer, which is what I’ve been trying to avoid.

If Coda lets developers supply a tokenPrefix option, we should also be able to set it to an empty string or “null”.

Thanks.

Code:

// pack.ts
pack.setUserAuthentication({
  type: coda.AuthenticationType.OAuth2,
  authorizationUrl:
    "https://blahblah.auth.us-east-1.amazoncognito.com/oauth2/authorize",
  tokenUrl:
    "https://blahblah.auth.us-east-1.amazoncognito.com/oauth2/token",
  scopes: ["openid", "email"],
  tokenPrefix: null,
});

Console output:

# npx coda upload pack.ts

Building Pack bundle...
Validating Pack metadata...
Pack metadata failed validation: [{"path":"defaultAuthentication.tokenPrefix","message":"Expected string, received null"}]: 
Error in field at path "defaultAuthentication.tokenPrefix": Expected string, received null
2

Hi @Chris_Gregory - Thanks for raising this issue. I’ve taken a look through out code, and it seems like the assumption that there will always be some prefix runs pretty deep and will likely be somewhat difficult to untangle. I’ll raise the issue with the team, but it may not be something they can get to in the near term.

Have you tried setting it to a single space? That shouldn’t trigger the fallback to “Bearer”, but I’m not sure if AWS is whitespace sensitive when it comes to header values.

3

Thanks for the suggestion Eric. I checked and the default authorizer does allow you to include a whitespace prefix and still authenticate, so I appreciate the suggestion.

Once I was unblocked there, I learned that the default authorizer doesn’t allow for authenticating access_tokens, only id_tokens, so I ended up having to use the custom authorizer I made anyway :roll_eyes: .

Thank you for your response! I was able to get around the limitation. Cheers.

4

Ah, bummer. On the positive side one of our engineers took a look and allowing for blank token prefixes turned out to be simpler than I suspected, so it’s something we should have live tomorrow. Unfortunately that doesn’t seem to solve the issue in your case, but hopefully it will help others that run into the same issue.

1 Like