You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Batching requests with different Authorization Headers doesn't work #2418
According to the Google API documentation, it should be possible to perform batch requests that have different Authorization headers:
The HTTP headers for the outer batch request, except for the Content- headers such as Content-Type, apply to every request in the batch. If you specify a given HTTP header in both the outer request and an individual call, then the individual call header's value overrides the outer batch request header's value. The headers for an individual call apply only to that call.
For example, if you provide an Authorization header for a specific call, then that header applies only to that call. If you provide an Authorization header for the outer request, then that header applies to all of the individual calls unless they override it with Authorization headers of their own.
Requests are built with different instances of \Google\Client:
$batched_requests = [];
//$tokens is an array of stored oAuth tokensforeach($tokensas$name => $token) {
$client = new \Google\Client();
$client->setUseBatch(TRUE);
$client->setAccessToken($token);
$client->setClientId(<clientId>);
$client->setClientSecret(<clientSecret>);
$client->setApplicationName(<appName>);
$client->setRedirectUri(<redirectUri>);
$client->addScope([
\Google\Service\Calendar::CALENDAR,
'email'
]);
$client->setAccessType('offline');
$service = new \Google\Service\Calendar($client);
$batched_requests[$name] = $service->events->listEvents($calendar_data);
}
Then a batch request is fed with those requests using one of the client instances:
From my understandings of the docs, the $client instance used to create the batch request will feed the outer request, while each inner request should observe their own $client authorization headers and override the outer ones.
But that is not the case: no matter what I do, the result is a request with only outer authorization headers and of course, any inner request that doesn't belong to the outer authorized user receives a 404 response.
I can't find any working way to batch those requests according to the documentation. Am I missing something?
TLDR: It's not possible to batch requests with separate access tokens
hello @VonStroheim ! Here's an example of the batch request. I believe as you have properly identified, the batch requests are only meant to be made with a single $client configuration.
What you're trying to do is associate each $request object with a different $client object. Unfortunately, this is not possible. When you make a batch request, all $request objects added to the batch will be made using the $client passed to the Batch instance:
// in your code, you pass a $client to the Batch object. This will be used to fulfill the single batch request$batch = new \Google\Http\Batch($client, FALSE, NULL, '/batch/calendar/v3');
Batch requests are made in a batch - meaning they are sent in as one request. So having multiple Authorization headers wouldn't be possible (or make logical sense).
You will need to make separate requests for each token.
Hi, thanks for the reply! Could you please confirm that not having multiple Authorization headers is a limitation of this specific php-client? Because the Google API documentation states otherwise:
The HTTP headers for the outer batch request, except for the Content- headers such as Content-Type, apply to every request in the batch. If you specify a given HTTP header in both the outer request and an individual call, then the individual call header's value overrides the outer batch request header's value. The headers for an individual call apply only to that call.
For example, if you provide an Authorization header for a specific call, then that header applies only to that call. If you provide an Authorization header for the outer request, then that header applies to all of the individual calls unless they override it with Authorization headers of their own.
Yes I can confirm this is a limitation in the PHP client. We do not support setting separate clients for each batch request.
The $request object that gets returned when setUseBatch is true does not contain any authentication information. This could be added in a feature request, but as this library is in maintenance mode, it's not likely something we will be supporting soon. However, feel free to open a feature request (or even better, a pull request to support the feature) pull request and we will try to address it.
Activity
[-]Batching requests with different Authorization Headers[/-]bshaffer commentedon Jun 28, 2023
TLDR: It's not possible to batch requests with separate access tokens
hello @VonStroheim !
Here's an example of the batch request. I believe as you have properly identified, the batch requests are only meant to be made with a single
$clientconfiguration.What you're trying to do is associate each
$requestobject with a different$clientobject. Unfortunately, this is not possible. When you make a batch request, all$requestobjects added to the batch will be made using the$clientpassed to theBatchinstance:Batch requests are made in a batch - meaning they are sent in as one request. So having multiple
Authorizationheaders wouldn't be possible (or make logical sense).You will need to make separate requests for each token.
VonStroheim commentedon Jun 28, 2023
Hi, thanks for the reply! Could you please confirm that not having multiple Authorization headers is a limitation of this specific php-client? Because the Google API documentation states otherwise:
bshaffer commentedon Jun 28, 2023
Yes I can confirm this is a limitation in the PHP client. We do not support setting separate clients for each batch request.
The
$requestobject that gets returned whensetUseBatchistruedoes not contain any authentication information. This could be added in a feature request, but as this library is in maintenance mode, it's not likely something we will be supporting soon. However, feel free to open afeature request (or even better, a pull request to support the feature)pull request and we will try to address it.bshaffer commentedon Jun 28, 2023
I've added #2467 to track this feature request (although again, your best chance of having it added would be to submit a PR with the enhancement)