1

I created an API Client on heroku on my account (hereinafter account A), and got it to install on another account (hereinafter account B) using the OAuth flow as described here: https://devcenter.heroku.com/articles/oauth#web-application-authorization

Started the flow on account B, accepted the permissions, which triggered the callback, where I exchanged the code to get the final tokens in the expected format:

{
  "access_token":"811235f4-16d3-476e-b940-ed5dfc7d6513",
  "expires_in":7199,
  "refresh_token":"036b9495-b39d-4626-b53a-34399e7bc737",
  "token_type":"Bearer",
  "user_id":"01234567-89ab-cdef-0123-456789abcdef",
  "session_nonce":"2bf3ec81701ec291"
}

( just to be clear, this is dummy data taken from the heroku documentation )

Up to here all was fine, however when I tried to use the token**, I got a very unexpected result: when I called the GET /apps endpoint, it returned the apps from account A instead of account B.

I can't make sense of why that would be the case, I have looked through the documentation profusely and can't find any explanation for that. If anyone has experienced this or has some explanation, I will gladly listen.

** by "use the token", I mean setting my header as Authorization: Bearer {access_token}, using python's requests library.

Dominus
  • 808
  • 11
  • 25

1 Answers1

1

It turns out it wasn't related to heroku directly, but instead to a very sly linux file, .netrc. To make it brief, this file can be used by applications to store tokens in plain text. The very strange thing is that the python module requests uses it by default, overwriting the header you give it with one generated from that file, if there is a match.

To check whether you have the same issue, simply check the existence of the .netrc file in your home folder, or check the logs to verify if the headers sent are the ones you expected.

Dominus
  • 808
  • 11
  • 25