This repository has been archived by the owner on Nov 10, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 198
Confusion about bearer tokens #387
Labels
Comments
Yea I'm working through the same issue. One thing I know is that if you open different projects you create different bearer_tokens but it would be useful to use different bearer tokens in the same project. I'm trying to work through the code and see if I can figure out what's going on. |
Closed
The problem might come from how the bearer are stored. They are added to the rtweet:::.state enviroment, so the second bearer token overwrites the first bearer token (if the second gets created at all!) See the internal |
hadley
added a commit
that referenced
this issue
Mar 5, 2021
The bearer token is no longer cached; it's not an expensive operation to retrieve it, it's app specific, and the user should be storing in a variable anyway. A bearer token is (nearly) equivalent to having the client app and secret, so I've made it harder to expose by accident with a new print method, and made it more difficult to use rtweets default app. The tests currently fail because invalidate_bearer() doesn't work, probably because I don't understand the asymmetry between getting an access token and invalidating an access token. Fixes #387
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I'm trying to understand bearer tokens better by using two tokens that I have for different applications.
I have two tokens,
token1
andtoken2
, that are clearly different:However, the corresponding bearer tokens are identical. When and why is this the case?
The text was updated successfully, but these errors were encountered: