Valid access token, but every call throws invalid access token

[marsderp]

I have been encountering a very weird situation where every call throws an invalid access token exception. I have double-checked the call manually (both with an outgoing sniffer and Postman calls) and it returns expected results.

This has been causing my error log to grow insanely fast. This is the relevant section from the logs:

[2016-05-04 19:08:22] 2020filmproject.ERROR: Larabros\Elogram\Exceptions\OAuthAccessTokenException: The access_token provided is invalid. in /var/www/filmproject/vendor/larabros/elogram/src/Http/Clients/AbstractAdapter.php:69

Stack trace:
#0 /var/www/filmproject/vendor/larabros/elogram/src/Http/Clients/GuzzleAdapter.php(49): Larabros\Elogram\Http\Clients\AbstractAdapter->resolveExceptionClass(Object(GuzzleHttp\Exception\ClientException))
#1 /var/www/filmproject/vendor/larabros/elogram/src/Repositories/UsersRepository.php(53): Larabros\Elogram\Http\Clients\GuzzleAdapter->request('GET', 'users/self/medi...', Array)
#2 /var/www/filmproject/app/Helpers/Gatherer/InstagramGatherer.php(88): Larabros\Elogram\Repositories\UsersRepository->getMedia('self', 50)

[hassankhan]

Is it possible your access token has expired? Have you tried retrieving one through the SDK or did you already have one from before?

[marsderp]

This issue is indeed occurring even with a brand new access token attained by authorization.

[hassankhan]

Thanks for the reply, I'll look into it later tonight :)

[marsderp]

Just a quick update - when I am running a console command, the call always succeeds on the first try and subsequently always fails (basically refreshing the feed/search) in the same process. Restarting the command always results in the same issue.

[hassankhan]

Would it be possible to some sort of a code sample? I'm not having much luck reproducing...

[marsderp]

Actually, I am encountering some more problems with this.

Imagine a scenario where I am running calls for multiple users in a single script, each using the user's access_token stored in a database after they gave authorization to the app.

Here is a very simplistic snippet from my console command. I believe I have narrowed down the cause to be in $client->setAccessToken($access_token);.

$client = new Client(env('INSTAGRAM_CLIENT_ID'), env('INSTAGRAM_CLIENT_SECRET'));

for ($i = 0; $i < 5; $i++) {
    $this->info('Running count ' . $i);

    $access_token = new AccessToken(['access_token' => '{ "access_token": "' . $user_access_token . '" }']);
    $client->setAccessToken($access_token);
    $result = $client->tags()->getRecentMedia('nike');

    $this->info(' - ' . count($result->get()->all()) . ' results to process.');

    sleep(2);
}

If we intercept and print the access_token in AuthMiddleware, this is the result:

> php artisan marsd:sample --token="___replaced___"
Running count 0
Access Token: ___replaced___
 - 20 results to process.

Running count 1
Access Token: { "access_token": "{ "access_token": "___replaced___" }" }


  [Larabros\Elogram\Exceptions\OAuthAccessTokenException]
  The access_token provided is invalid.

I have found a solution to this in the meantime, that is to declare a new Client with an access_token everytime in the constructor like so:

$access_token = new AccessToken(['access_token' => '{ "access_token": "' . $user->instagram_access_token . '" }']);
$client       = new Client(env('INSTAGRAM_CLIENT_ID'), env('INSTAGRAM_CLIENT_SECRET'), $access_token);

I'm not sure if this issue is worth exploring further, but this could be a nice-to-know for other users who may have similar use cases.

[hassankhan]

Thank you so much for your detailed reply, using multiple access tokens was never something I actually got round to testing. I agree with your assessment of setAccessToken(), I'll try and take a look at it today (sorry, never got time yesterday)

[hassankhan]

I've just tagged 1.2.2 which should solve the issue, please let me know if it hasn't.

[hassankhan]

Any luck, @MarSD?

[IvoPereira]

I'm facing the same problem and the last version has not solved the problem for me.

Any other ideas? I've seen the suggestion of using the access token wrapped of a JSON, but that did not work to me aswell.

Thanks