1

When we are accessing Asana API we are using the Asana node client v0.15.0 together with an Tampermonkey script. The Api is responding with an 401 (Unauthorized).

This worked a couple a days ago. I have tried with new Personal Access Tokens but still get the same error. While fiddling the request I tried to change the auth-header Bearer to be lower cased.

Authorization: Bearer my-personal-access-token -> Authorization: bearer my-personal-access-token.

This seems to work fine, that indicates that something changed on Asana's side.

The node-asana js client lib does not let me modify the request before sending it to Asana API.

According to Asana API support it is on stackoverflow that I should ask about help on this matter.

EDIT

By some further investigation it seems that when we send in the cookie auth_token=My auth token we do get the 401 error. But If removing the cookie and reissue the request in fiddler it works fine.

Another note is that now we do not get any custom_fields in the response from e.g https://app.asana.com/api/1.0/tasks/TaskId

Fredrik Öberg
  • 87
  • 1
  • 6

1 Answers1

3

I'm a Developer Advocate at Asana. You've caught something that is a known issue and we're working on a fix :) We're rolling out a new version of our API. It's intended to be backwards-compatible with the older implementation, but giving us multiple forms of authentication is one of those cases where we do something different between the two.

For security purposes, we initially implemented this in the new version to not allow requests with multiple forms of authentication, but it turns out that in-browser integrations were affected in precisely the way you're seeing: being logged into Asana, which causes your browser to send your authorization credentials for requests to asana.com automatically, and also authorizing "the right way" for our API with OAuth or a Personal Access Token will end up breaking. We're working on a fix that will allow this to work for the case when both the logged in (cookie) user and the API (access token) user are the same.

If this is an urgent issue and you want to force the old behavior to happen while we roll out the fix in our newer API implementation, you can set a header as described in that link --^ to force your requests on to the old API. Once we get the new API fully deployed and stable, though, we'll deprecate that header, so please be cautious in relying on it for a long-term solution.

Sorry that this has caused issues for you, and thanks for creating this question to let us know!

Matt
  • 10,434
  • 1
  • 36
  • 45
  • Thanks for the explanation! We did a workaround so we use the OAuth2 instead of access tokens and it works fine for us. The issue with not getting the _custom_fileds_ seems to be resolved as well. – Fredrik Öberg Feb 06 '17 at 11:43