cwhite92
Allow caching of authorization request
This pull requests adds a generic parameter to the construct option to provide an existing authorization object and allows you to get the authorization details from an existing connection. This way it is possible by the user to implement their own caching mechanism.
Example usage with Redis caching could be:
// Check if we have an authorization object available in Redis
$redis = \Redis::getInstance();
$auth = $redis->get('b2_auth');
if(!empty($auth)){
// If available, decode object and use to init library
$auth = json_decode($auth, true);
$this->client = new \ChrisWhite\B2\Client(B2_ID, B2_KEY, ['authorization' => $auth]);
} else {
// If not, generate init with new authorization request and save to Redis afterwards
$this->client = new \ChrisWhite\B2\Client(B2_ID, B2_KEY);
$authorization = $this->client->getAuthorization();
// Save authorization object to Redis, expire in 23 hours so we don't use any expired tokens
$redis->set('b2_auth', json_encode($authorization, JSON_UNESCAPED_SLASHES));
$redis->expire('b2_auth', 60 * 60 * 23);
}
I do not know what to think of this. I understand the need, however, the implementation bothers me. With the current deisgn, you have to provide the tokens from outside the library, meaning you have to do the authorization somewhere outside of the library as well.
@iammichiel I choose explicitly for the current design as to make it as generic as possible so everybody can choose their own caching method.
Authorization doesn't happen outside the library, it allows you to retrieve the authorization token after the initial connection by the library and insert it into the library again at a later time.
I'm with @iammichiel here. Perhaps provide a cache adapter that can be injected in to the library?
I still think and agree that this is a nice quickfix @Wouter33. My solution is quite similar.
@OscarEriksen A cache adapter plugin possibility and the cache adapters themselves require a much bigger overhaul and limit the freedom to use whatever the user want. I agree that that would be better and the ideal situation, but looking at this repo's activity and actual contributions i doubt how realistic it is that we will be getting that in the near future. At least this pull request will allow some sort of caching by users without forking the repo.
I agree with you. It's a nice quickfix and opens up for further development. @cwhite92 input?
If anyone wants to create a fork (seeing as the current maintainer doesn't really have time, no hard feelings) and work on an up-to-date php-library for Backblaze where the aim is to cover issues such as this, then I'd like to join in. And I think Backblaze would be greatly appreciative of it as well.
I forked the repo and merging the PRs in there. You can access it here: https://github.com/tarikozket/b2-sdk-php
