возникли проблемы при сравнении свойства jwt.iat (выданного в) с текущим значением datetime - (NumericDate "Seconds Since the Epoch") - PullRequest
Новая
       78

возникли проблемы при сравнении свойства jwt.iat (выданного в) с текущим значением datetime - (NumericDate "Seconds Since the Epoch")

0 голосов
/ 30 октября 2019

Я получаю веб-токен json от веб-службы, которая при декодировании возвращает что-то вроде этого: 

{
  "exp": 1572468916,
  "iat": 1572468316,
  "iss": "https://ccc/auth/realms/yyy",
  "aud": "xxx-api",
  [...]

Согласно Terminalogy раздела 2 тип данных NumericDate соответствует«Секунды с начала эпохи»

Поэтому я конвертирую ее в дату Javascript, например: 

new Date(1572468316 * 1000)
Date Wed Oct 30 2019 17:45:16 GMT-0300 (Argentina Standard Time)

Проблема в том, что мое текущее время: 

new Date()
Date Wed Oct 30 2019 14:45:19 GMT-0300 (Argentina Standard Time)

Фактически, текущее время - это время, возвращаемое из new Date() (то есть 14:45, нет 17:45)

Я думаю, это как-то связано с GMT, но я не знаю, какобработать его.

Я хочу преобразовать свойство iat (и, очевидно, тоже свойство exp) в текущее время, чтобы сравнить его с new Date(), чтобы выяснить, истек ли токен или нет.

Так как я могу преобразовать NumericDate из свойства iat / exp веб-токена json в мое местное время для сравнения?

1 Ответ

1 голос
/ 31 октября 2019

Значения iat и exp действительно выражены в секундах с эпохи Unix. Поскольку эпоха Unix основана на UTC, то же самое относится и к этим значениям. Вы преобразуете их в Date объекты правильно. 

var iat = new Date(1572468316 * 1000);
var exp = new Date(1572468916 * 1000);

console.log(iat.toISOString()); //=> "2019-10-30T20:45:16.000Z"
console.log(exp.toISOString()); //=> "2019-10-30T20:55:16.000Z"

Функция toISOString генерирует строку в формате ISO 8601, представленную как UTC (как указано конечным символом Z).

Формат вывода, который вы задали в своем вопросе, заключается в том, что произойдет при вызове функции toString или при непосредственном протоколировании объекта Date в среде, которая выбирает запись вывода toString. Поскольку разные среды могут испускать разные форматы (некоторые по местному времени, некоторые в UTC, некоторые в ISO 8601, некоторые в нестандартном формате) - не рекомендуется напрямую регистрировать объект Date.

вывод toISOString показывает, что JWT действовал в течение 10 минут, с 2019-10-30 20:45:16 UTC до 2019-10-30 20:55:16 UTC. Нет другого способа интерпретировать эти результаты.

Ваш вывод по местному времени показывает трехчасовое преобразование, которое будет правильно соответствовать смещению часового пояса UTC-3, снова подтверждая, что их значения анализируются правильно.

Если это не то, что вы ожидали, токен был выдан неправильно. Происходит одна из двух вещей:

  • В коде, генерирующем JWT, может быть ошибка, связанная с использованием локального времени вместо UTC в качестве основы для созданияотметка времени.

  • На сервере, на котором запущен код, в котором был сгенерирован JWT, часы могут быть установлены неправильно.

Второй вариант более вероятен,Например, это может произойти, когда администратор сервера устанавливает часовой пояс в формате UTC, но устанавливает часы на основе местного времени. Вместо этого убедитесь, что часы на сервере настроены на автоматическую синхронизацию времени из Интернета, и проблема, скорее всего, исчезнет.

Что касается подхода, упомянутого в комментариях к вопросу - не делайте этого. Вычитание смещения часового пояса таким образом не корректно корректируется для часовых поясов, а скорее выбирает другой момент времени. Может показаться, что он дает правильные результаты, но вы найдете крайние случаи перехода на летнее время во многих часовых поясах, и у вас возникнут проблемы, когда JWT начнут генерироваться с правильными значениями.

...