Getting authentication issues after updating to latest typed-rest-client

[christiango]

Environment

Node version: 12.13.0
Npm version: 6.12.0
OS and version: Windows 10
azure-devops-node-api version: 10.1.1

Issue Description

We use the azure-devops-node-api in some Azure Devops pipeline to do things like write comments to the PR. This was working fine until 11/6/2020 when we happened to have an auto update of our lockfile that took typed-rest-client (which is a dependency of azure-devops-node-api) from version 1.7.3 to 1.8.0.

What we are seeing is the following error

Error: TF400813: The user '' is not authorized to access this resource.
    at s (/home/vsts/work/1/a/bundle-buddy-cli/bundleBuddyCli.js:41:48158)
    at processTicksAndRejections (internal/process/task_queues.js:93:5) {
  statusCode: 401,
  result: {
    '$id': '1',
    innerException: null,
    message: "TF400813: The user '' is not authorized to access this resource.",
    typeName: 'Microsoft.TeamFoundation.Framework.Server.UnauthorizedRequestException, Microsoft.TeamFoundation.Framework.Server',
    typeKey: 'UnauthorizedRequestException',
    errorCode: 0,
    eventId: 3000
  }
}

When using --inspect-brk to break on this error, it seems to be happening on an options call that gets triggered when we call getGitApi and then it makes a call to ._getResourceAreaUrl

public async getGitApi(serverUrl?: string, handlers?: VsoBaseInterfaces.IRequestHandler[]): Promise<gitm.IGitApi> {
    serverUrl = await this._getResourceAreaUrl(serverUrl || this.serverUrl, gitm.GitApi.RESOURCE_AREA_ID);
    handlers = handlers || [this.authHandler];
    return new gitm.GitApi(serverUrl, handlers, this.options);
}

We reverted types-rest-client in our lockfile back to 1.7.3 and everything is working again on our side. Logging the issue in case others hit this or in case someone knows of a fix.

[johnnyreilly]

Maybe it's worth putting an issue against the repo:

https://github.com/microsoft/typed-rest-client

I wonder if this might be related to: microsoft/typed-rest-client#238 or microsoft/typed-rest-client#223

cc @anatolybolshakov @damccorm @mastrzyz

[damccorm]

@anatolybolshakov could you or your team take a look?

[JamieMagee]

I dug into this a bit more, as I'm being hit by it. It looks like this commit introduced the issue.

I think the solution is to set allowCrossOriginAuthentication to true, or the very least, expose it as a parameter in the authentication handler methods

[anatolybolshakov]

@JamieMagee thanks for digging into this! I created PR with exposing this as a parameter.

[JamieMagee]

@anatolybolshakov Thanks for the quick PR. Can you publish version 10.1.2 to npm?

[jjguijt]

I have encountered the same issue, a quick push to npm would be appreciated. Thanks for the quick work on this!

[damccorm]

This has been published

[anatolybolshakov]

Thanks @damccorm!
@christiango @JamieMagee @jjguijt could you please check that it works for you currently?

[johnnyreilly]

I think it might not be fixed - just experimenting.

[johnnyreilly]

I'm experiencing this:

TF400813: The user '' is not authorized to access this resource.

Error: TF400813: The user '' is not authorized to access this resource.
    at RestClient.<anonymous> (/home/vsts/work/1/s/node_modules/typed-rest-client/RestClient.js:202:31)
    at Generator.next (<anonymous>)
    at fulfilled (/home/vsts/work/1/s/node_modules/typed-rest-client/RestClient.js:6:58)
    at processTicksAndRejections (internal/process/task_queues.js:93:5) {
  statusCode: 401,
  result: {
    '$id': '1',
    innerException: null,
    message: "TF400813: The user '' is not authorized to access this resource.",
    typeName: 'Microsoft.TeamFoundation.Framework.Server.UnauthorizedRequestException, Microsoft.TeamFoundation.Framework.Server',
    typeKey: 'UnauthorizedRequestException',
    errorCode: 0,
    eventId: 3000
  }
}

However I've pinned to 1.7.3 and am still experiencing the issue - it's possible my own issue is different

  "resolutions": {
    "typed-rest-client": "1.7.3"
  }

[johnnyreilly]

Yup - it was a different issue. This works for me!

[christiango]

Confirmed the latest version works when you pass the new parameter through to the handlers. Thanks for the quick turnaround!