Автор оригинала: David Wong.
Мой блог на GitHub: https://zgxxx.github.io/
Последняя статья в блоге https://segmentfault.com/a/11… Представляет несколько шагов laravel с использованием dingo + JWT для разработки API. На практике нам нужно протестировать API
$api = app('Dingo\Api\Routing\Router'); $api->version('v1', ['namespace' => 'App\Http\Controllers\V1'], function ($api) { $api->post('register', '[email protected]'); $api->post('login', '[email protected]'); $api->post('logout', '[email protected]'); $api->post('refresh', '[email protected]'); $api->post('me', '[email protected]'); $api->get('test', '[email protected]'); });
Эти маршруты заданы, и соответствующий URL-адрес похож на этот: http://www.yourweb.com/api/me использует postman для отладки этих API.
Общий процесс запроса API
Мы используем JWT вместо сеанса. Во-первых, мы используем логин (метод попытки JWT для проверки пароля учетной записи). После успеха JWT будет возвращен. Мы называем это строковым токеном. Этот токен должен быть сохранен нашим клиентом. Затем интерфейс, который должен быть аутентифицирован позже, содержит этот маркер в заголовке запроса. После того, как проверка фона будет выполнена правильно, будет выполнена следующая операция. Если ошибка токена, или ошибка 401 или 500, будет возвращена по истечении срока действия, и последующие операции будут отклонены.
Интерфейс можно сохранить в localstorage, а апплет можно сохранить с помощью wx.установите синхронизацию хранилища
Таким образом, авторизация информации заголовка запроса: носитель + токен очень важна, но есть проблема. У этого токена есть время обновления и время истечения срока действия: 'ttl' => env('JWT_TTL', 60), 'refresh_ttl' => env('JWT_REFRESH_TTL', 20160),
- Refresh_ttl-это время истечения срока действия. По умолчанию это 14 дней. Это легко понять. Как и на некоторых веб-сайтах, если вы не войдете в систему в течение нескольких месяцев, ваша учетная запись автоматически выйдет из системы. Поскольку срок его действия истек, вам необходимо повторно ввести пароль учетной записи для входа в систему.
- Время обновления TTL по умолчанию составляет 60 минут. То есть вы не можете попросить жетон час назад. Вы сообщите об ошибке токена, внесенного в черный список, что означает, что старый токен был внесен в черный список и не может быть использован
Токен будет украден другими, поэтому токен необходимо обновлять каждые два периода времени
В это время существует проблема, которая обновляется каждый час. Разве не нужно каждый час снова входить в систему, чтобы получить новый токен? Конечно, в этом нет необходимости. Мы можем написать промежуточное программное обеспечение для безболезненного обновления токенов. Пользователи не заметят, что мы обновили токен.
php namespace App\Http\Middleware; use Closure; use Tymon\JWTAuth\Exceptions\JWTException; use Tymon\JWTAuth\Http\Middleware\BaseMiddleware; use Tymon\JWTAuth\Exceptions\TokenExpiredException; use Symfony\Component\HttpKernel\Exception\UnauthorizedHttpException; class RefreshToken extends BaseMiddleware { /** * @author: zhaogx * @param $request * @param Closure $next * @return \Illuminate\Http\JsonResponse|\Illuminate\Http\Response|mixed * @throws JWTException */ public function handle($request, Closure $next) { //Check whether there is a token in the request, and if not, throw an exception. $this->checkForToken($request); //Use try wrap to catch tokenexpiredexception exception thrown by token expiration try { //Check the login status of the user, and if it is normal, pass the if ($this->auth->parseToken()->authenticate()) { return $next($request); } Throw new unauthorized httpexception ('jwt auth ',' not logged in '); } catch (TokenExpiredException $exception) { //The tokenexpiredexception exception thrown by token expiration is caught here. What we need to do here is refresh the user's token and add it to the response header try { //Refresh user's token $token = $this->auth->refresh(); //Use one-time login to ensure the success of this request \Auth::guard('api')->onceUsingId($this->auth->manager()->getPayloadFactory()->buildClaimsCollection()->toPlainArray()['sub']); } catch (JWTException $exception) { //If this exception is caught, that is to say, refresh also expires. The user cannot refresh the token and needs to log in again. throw new UnauthorizedHttpException('jwt-auth', $exception->getMessage()); } } return $next($request)->withHeaders([ 'Authorization'=> 'Bearer '.$token, ]); } }
Как только промежуточное программное обеспечение обнаружит, что токен устарел, оно автоматически обновит токен, а затем вернет новый токен в заголовке ответа. Наш клиент может решить, следует ли заменять токен в соответствии с тем, есть ли “авторизация” в заголовке ответа При использовании postman для отладки этих API, возникает проблема. У почтальона нет кода интерфейса. Как я могу своевременно обновить этот токен? Должен ли я смотреть на заголовок ответа каждый раз, когда я его прошу? Нужно ли мне копировать и вставлять его вручную после обнаружения авторизации? Конечно, в этом нет никакой необходимости. У почтальона есть мощная переменная окружения, которая также является частью JS.
Токен заголовка запроса на автоматическое обновление почтальона
Получите токен автоматически после входа в систему
Сначала нажмите кнопку настройки среды и нажмите кнопку добавить, чтобы добавить переменную. Мы устанавливаем значение ключа для доступа к токену подразделения,
Затем мы назначаем эту переменную тестам в интерфейсе входа в систему
var data = JSON.parse(responseBody);
if (data.result.access_token) {
tests["Body has token"] = true;
var tokenArray = data.result.access_token.split(" ");
postman.setEnvironmentVariable("access_token", tokenArray[1]);
}
else {
tests["Body has token"] = false;
} Этот код JS предназначен для получения значения access_token, возвращаемого после успешного выполнения запроса, и присвоения его переменной среды postman. Мы видим, что после успешного выполнения запроса мы возвращаем JSON в фоновом режиме, который содержит нужный нам access_token. Мы можем снова перейти к переменной среды, чтобы посмотреть, что изменяется в это время
Вы можете видеть, что переменная access_token здесь имеет значение, которое является строкой access_token, возвращаемой из фона, указывающей на то, что назначение выполнено успешно
Затем мы переходим к другому тесту интерфейса, который должен быть сертифицирован, Мы выбираем токен на предъявителя в типе типа авторизации и вводим ” {“в форме токена, которая автоматически запрашивает переменную, которую мы установили {{токен доступа ﹣ u}} Отправить запрос тест прошел успешно.
Маркер безболезненного обновления
Если токен обновлен, новый токен будет возвращен в заголовке ответа после безболезненного обновления фонового промежуточного программного обеспечения (для этого запроса используется старый токен, и проходит аутентификация по умолчанию)
Теперь нам нужно обновить наш токен подразделения переменного доступа непосредственно в этом интерфейсе (как показано на рисунке ниже), вместо того, чтобы снова запрашивать интерфейс входа в систему
var authHeader = postman.getResponseHeader('Authorization');
if (authHeader){
var tokenArray = authHeader.split(" ");
postman.setEnvironmentVariable("access_token", tokenArray[1]);
tests["Body has refreshtoken"] = true;
} else {
tests["Body has no refreshtoken"] = false;
}Этот код JS предназначен для назначения авторизации в заголовке ответа нашему access_token
Это авторизация заголовка ответа, который перехватывает последнюю строку
По истечении времени обновления мы пытаемся отправить другой запрос. Мы видим, что он по-прежнему доступен, и авторизация в заголовке запроса была обновлена автоматически
Одним словом, вам нужно обновить переменные, после чего интерфейс ответит. Перейдите к тестированию этого интерфейса и напишите код назначения JS postman.SetEnvironmentVariable("access_token", токен); Если ошибок нет, вы можете использовать {{доступ {токен}} для обновления и замены его в другом месте.
Оригинал: “https://developpaper.com/using-postman-to-debug-the-interface-developed-by-jwt/”