Когда работаешь в проекте со сторонними апи предоставляющими какой-либо сервис, то необходимо делать к ним запросы с бэкенда и как по мне, делать это с бекэнда бывает не так удобно как с фронтенда. Тем более если нужное апи авторизует запросы по временному токену, который действует только какое-то время (обычно 24 ч.) и потом становится не действительным. В данной статье будет рассмотрен способ автоматического обновления такого токена непосредственно в процессе запроса ресурса удалённого сервиса.

Существует несколько способов аутентификации http запросов. Один из них использование постоянного api-key в заголовке или в query части запроса, который добавляется ко всем запросам требующим авторизации. Так (по заголовоку) например работает api яндекс такси. Другой тип аутентификации, это также использование заголовка Authorization с токеном, который может быть временным и для получения которого используется другой метод авторизации по логин-паролью. Так например, работали ситимобил и гетт. В случае когда такой токен (временный) истекает, то необходимо вновь пройти авторизацию через логин-пароль. Сам токен в свою очередь может быть выпущен в виде jwt (json web token). В целом первый способ называется авторизация по api key, а вторая bearer авторизацией.

В данной статье для примера будем использовать апи сервиса mercuryo. У данного сервиса апи реализовано по видоизменённой схеме с комбинацией api-key и временным jwt в качестве его значения. Для первичной аутентификаци используется запрос к методу sign-in по стандартной api-key схеме с использованием постоянного Sdk-Partner-Token. В ответе приходит временный jwt с помощью, которого уже и делаются запросы к ендпроинтам апи. Кроме того, есть возможность обновить валидный (не истёкший) jwt с помощью метода /refresh-token. В данном случае идёт речь об партнёрском апи, через которое партнёр может подключать своих пользователей к сервису и управлять их действиями из своего интерфейса. Соответственно все методы апи применяются к этому пользователю, а не к партнёру как таковому. В том числе и sign-inи остальные. Идентификация пользователей происходит по jwt. А при первоначальном логине используется почта (или телефон/ууид юзера).

Для работы с истекающими токенами можно хранить время получения токена и время его действия. Тогда при запросе можно проверить действителен ли ещё токен и если нет, то пройти повторную аутентификацию. В данной статье мы рассмотрим другой способ, который основан на использовании клиента, который в случае ответа 401 UnAuthorized делает запрос на повторную аутенфикацию и делает повторный запрос с новым токеном без участия со стороны пользователя таким клиентом..

В одной из наших предыдущих статей мы использовали общий класс отправитель различных сообщений Sender. Он ничего из себя не представлял, кроме одного метода с вызовом в нём метода send на http клиенте. Взяв его за основу добавим в него функциональность необходимую для получения желаемого от него поведения. Для этого используем код на основе генераторов добавим ему слой middleware.

<?php

namespace app\services\backend\email;

use app\interfaces\MessageInterface;
use app\interfaces\SenderInterface;
use app\models\Email\RestMessage;
use app\services\backend\infrastructure\ClientInterface;
use Generator;
use yii\base\InvalidConfigException;
use yii\httpclient\Client;
use yii\httpclient\Exception;
use yii\httpclient\Response;

class Sender implements SenderInterface
{
    private array $middlewares;
    private int   $currentMiddleware = 0;
    private RestMessage $message;
    /** @var Client $client */
    private $client;
    private Response $response;

    public function __construct(ClientInterface $client)
    {

        $this->client = $client;
    }

    public function send(MessageInterface $message)
    {
        /** @var RestMessage $message */
        $this->message = $message;
        /** @var Generator $gen */
        $gen = $this->trySend($message);
        foreach ($gen as $n => $s) {
            $this->next();
        }
        /** @var Response $res */
        $res = $gen->getReturn();
        return $res;
    }

    /**
     * @throws Exception
     * @throws InvalidConfigException
     */
    public function trySend(MessageInterface $message)
    {
        $statusCode = null;
        $n = 0;
        while ($statusCode != 200 && $n < 2) {
            $res = $this->client->send($this->message);
            $this->response = $res;
            $statusCode = $res->getStatusCode();
            $n++;
            if ($statusCode != 200){
                yield $res;
            }
        }
        return $res;
    }

    public function middleware(array $middlewares): self
    {
        foreach ($middlewares as $closure) {
            $this->middlewares[] = $closure;
        }
        return $this;
    }

    public function next()
    {
        $current = $this->currentMiddleware++;
        if (isset($this->middlewares[$current])) {
            $do = $this->middlewares[$current]($this->message, $this->response, [$this, 'next']);
            if (!$do) {
                $this->currentMiddleware = 0;
            }
        } else {
            $this->currentMiddleware = 0;
        }
    }
}

Теперь в методе Sender::send() создаётся генератор на основе которого в цикле foreach происходят вызовы метода Sender::trySend() через итератор и вызовы middleware через Sender::next() в теле цикла. В методе Sender::trySend() делаются запросы через клиент пока не будет получен ответ со статусом 200 или n < 2. Если статус ответа не 200, то возвращается новый элемент для внешнего цикла foreach в котором выполняется запуск выполнения middleware. Соответственно, после выполнения всех middleware происходит новый запрос через клиента.

Теперь рассмотрим применение middleware для повторного запроса к апи с обновлённым токеном в MercuryoClient::class.

<?php

namespace app\services\backend\finance\crypto;

use app\interfaces\finance\crypto\CryptoClientInterface;
use app\interfaces\SenderInterface;
use app\models\Email\RestMessage;
use app\models\User\User;
use app\services\backend\email\Sender;
use app\services\backend\infrastructure\ClientInterface;
use app\services\backend\infrastructure\RestClient;

class MercuryoClient implements CryptoClientInterface
{
    private Sender     $sender;
    private RestClient $client;
    private string     $ua;
    private string     $token;

    public function __construct(
        SenderInterface $sender,
        ClientInterface $client,
        string          $token,
        string          $userAgent
    )
    {
        $this->sender = $sender;
        $this->client = $client;
        $this->token  = $token;
        $this->ua     = $userAgent;
    }

    /**
     * Register user in the mercuryo
     * @param string $email
     * @return mixed
     */
    public function signUp(string $email)
    {
        $message = $this->createMessage(
            'POST',
            'user/sign-up',
            [
                'accept' => true,
                'email' => $email
            ]
        );
        $message->addHeaders(['Sdk-Partner-Token' => $this->token]);
        $res = $this->sender->send($message);
        return $res;
    }

    /**
     * Login user in the mercuryo
     * @param string $email
     * @return mixed
     */
    public function signIn(string $email)
    {
        $message = $this->createMessage(
            'POST',
            'user/sign-in',
            [
                'email' => $email
            ]
        );
        $message->addHeaders(['Sdk-Partner-Token' => $this->token]);
        $res = $this->sender->send($message);
        return $res;
    }

    public function getUserData(User $user)
    {
        $message = $this->createMessage(
            'GET',
            'user/data'
        );
        $token = $user->mercuryo->bearer_token;
        $message->addHeaders(['b2b-bearer-token' => $token]);
        $res = $this->sender
            ->middleware([
                    [ReSignInMiddleware::class, 'execute'],
                    [RefreshMiddleware::class, 'execute']
            ])
            ->send($message);
        return $res;
    }

    public function refreshTokenInMiddleware(string $token)
    {
        /** @var RestMessage $message */
        $message = $this->createMessage('GET', 'user/refresh-token');
        $message->addHeaders(['b2b-bearer-token' => $token]);

        $res = $this->sender->send($message);
        return $res;
    }

    public function createMessage(string $method, string $url, array $data = [])
    {
        $request = new RestMessage($this->client);
        $request->setMethod($method)
        ->setUrl($url)
        ->setHeaders([
            'Content-Type' => 'application/json',
            'Accept' => 'application/json',
            'User-Agent' => $this->ua,
        ])
        ;
        if (!empty($data)) {
            $request->setData($data);
        }
        return $request;
    }
}

В методах signIn и signUp аутентификация происходит по постоянному api-keу Sdk-Partner-Token в заголовке. В методах getUserData и refreshTokenInMiddleware аутентификация происходит уже по временному jwt поэтому в случае если он истекает, то используется ReSignInMiddleware::execute middleware для его обновление в процессе запроса данных в методе MercuryoClient::getUserData(). Теперь рассмотрим как устроен класс ReSignInMiddleware который выступает в качестве промежуточного слоя.

<?php

namespace app\services\backend\finance\crypto;

use app\interfaces\finance\crypto\CryptoClientInterface;
use app\models\Email\RestMessage;
use Throwable;
use Yii;
use yii\httpclient\Response;

class ReSignInMiddleware
{
    public static function execute($message, $response, $next)
    {
        /** @var Response $response */
        $status = $response->getStatusCode();
        if ($status == 401) {
            /** @var RestMessage $message */
            /** @var MercuryoClient $s */
            try {
              //...
                $s = Yii::$container->get(CryptoClientInterface::class);
                $res = $s->signIn($mercuryo->user->email);
                $data = $res->getData();
                $message->addHeaders([
                    'b2b-bearer-token' => $data['data']['bearer_token']
                ]);
              // ...
            } catch (Throwable $e) {
                Yii::error($e->getMessage(), 'mercuryo');
                Yii::error($e->getTraceAsString(), 'mercuryo');
            }
        }
        return $next();
    }
}

Собственно говоря, если статус ответа 401, то с помощью MercuryoClient делается запрос MercuryoClient::signIn () на аутентификацию (строка 23), получается и подставляется в заголовок сообщения которое отсылалось изначально (строка 25). Тут нужно отметить важный момент, что Yii::$container->get(CryptoClientInterface::class) возвращает разные объекты MercuryoClient, а не один и тот же. Потому что иначе $this->message в классе Sender перезатирается в методе send.

Таким образом, происходит обновление временного токена (jwt) в процессе запроса данных пользователя через наш класс Sender и middleware ReSignInMiddleware.

Да, собственно сам вызов getUserData выглядит так:

<?php
$user = User::findOne($idUser);
/** @var MercuryoClient $s */
$s = Yii::$container->get(CryptoClientInterface::class);
/** @var Response $r */
$r = $s->getUserData($user);