Sorry, you are not authorized to see the user with id

[ghnp5]

Hello,
Thank you for providing this SDK :)

I'm using your authenticate.php and index.php example.
I get the access token successfully,
but then, for some reason, I'm not able to see my own tweets.
My account is protected, but I should be able to see my own tweets! :)
(it works for public users)

->me()->myself() returns my own user, so the access token is definitely being set.

But when I do $user->tweets(), I get this:

Sorry, you are not authorized to see the user with id: [MY_USER_ID]

MY_USER_ID being the correct user ID - I double checked that.

Do you have any idea what could be the problem?

My scopes:

	'scope' => [
		'tweet.read',
		'users.read',
		'follows.read',
		'like.read',
		'list.read'
	]

And the Authorization page also mentions that my app will be able to see protected tweets too.

Thanks!

[ghnp5]

Ok, I resolved the problem.

Bearer tokens provide no user context, so these will never work for accessing protected or private resources. You will definitely need a relevant access token and secret / OAuth 1.0A for these endpoints.

'bearer_token' should be also $token->getToken(), and not the Bearer Token that is in the Developer Portal.

--

This is not clear anywhere, while I researched, but a hint here and there made me give it a try.

https://twittercommunity.com/t/cannot-access-protected-tweets-lists-via-the-api/150500
redouane59/twittered#157

Cheers!

[Dan Devine]

Glad you figured it out, let me know if you think there should be something in Bird Elephant docs to clarify this, although I think it's more for the Twitter docs.

[ghnp5]

Thanks @danieldevine -- I'm honestly REALLY confused :)

I'm trying to understand what my Rate Limits are at the moment, but I can't see the headers as per #48

By looking at the code of this repository, auth_token is what I want to use for PKCE authentication.
However, as per the above finding in this Issue, only bearer_token was accepted by the library.

I want to make sure I'm using the "User-context Rate Limits" rather than "App-only Rate Limits".

For sure, the requests are user-context, in terms that the scopes are working, and me() returns the user that just authenticated.

--

What I don't understand is this part:

        if ($signed === false) {
            $token = $this->credentials['bearer_token'];
            return $this->bearerTokenRequest($args, $token);
        }

        if (isset($this->credentials['auth_token'])) {
            $token = $this->credentials['auth_token'];
            return $this->bearerTokenRequest($args, $token);
        }

First, how can I manage $signed to be true/false.

Second, whether it's bearer_token or auth_token, it calls the exact same function (bearerTokenRequest), and it will do the exact same whether it takes from bearer_token or auth_token.

So I'm confused whether there's any difference at all by providing bearer_token or auth_token.

Cheers!

--

Edit, for info,
I confirm I'm definitely on User-Context Rate Limits, as per the headers returned:

  ["x-rate-limit-limit"]=>900
  ["x-rate-limit-reset"]=>1669337889
  ["x-rate-limit-remaining"]=>899

[Dan Devine]

@ghnp5 Interesting, I'll take a look at this and #48 over the weekend.

[Dan Devine]

Update: am finally looking at this now, have been extraordinarily busy.

[ghnp5]

Thanks very much! Happy 2023! 🥳🍾

[Dan Devine]

Thanks for this input which has raised some design questions and is prompting me to rethink the Request class somewhat. I'm currently working on an updated version of this, but I need to be conscious of not breaking existing implementations - it's a small library but has 20k+ installs in the wild - so it will take a bit of time to test.

When I first wrote the class a couple of years ago there were only 2 possible authentication methods - OAuth 1.0a User Context and OAuth 2.0 App Only and that binary paradigm influenced the naming and design. Since then Twitter enabled the use of OAuth 2.0 Authorization Code with PKCE. Bird Elephant was updated to allow that but the naming didn't change, so effectively any OAuth 2.0 request rus through the bearerTokenRequest() method.
I suppose you could make a case that pedantically, this is 'correct ' enough as the auth header is set to 'bearer' either way, but as you discovered it makes the class very hard to decipher.

In line with the overall philosophy of the library, ideally the methods should automatically use the appropriate authentication method for any endpoint but I'm exploring the possibility of making this user-editable.

These changes should become available soon , appreciate your patience.