JSON Web Token и ошибка 2038 года
JSON Web Token - сравнительно недавний стандарт (май 2015 г.), и все же они решили использовать метки времени UNIX для представления дат.
Разве это не подвергает стандарт потенциальной проблеме 2038 года в различных реализациях? Вместо этого стремление к чему-то похожему на ISO8601 кажется более перспективным.
Почему выбирают одно над другим?
1 ответ
JSON не накладывает ограничений на точность чисел, поэтому сам формат JWT не имеет проблем с переполнением. Все зависит от реализации.
Некоторые реализации, такие как JavaScript, обрабатывают все числа JSON как числа с плавающей запятой двойной точности. Хотя они не переполнятся до тех пор, пока не наступит тепловая смерть Вселенной, они начнут становиться неточными примерно через 300 миллионов лет, и со временем проблема будет только усугубляться (такие проблемы, как создание токена, который истекает через один час, но это значение не может быть выражено как число с плавающей запятой двойной точности, ближайшее значение находится через 2 часа, поэтому срок его действия не истекает до 2 часов).
Другие реализации могут использовать 64-битные целые числа со знаком. Они переполнятся через 300 миллиардов лет, намного позже, когда Солнце станет красным гигантом и поглотит Землю.
Единственные реализации, которые уязвимы для проблемы Y2038, - это реализации, которые решают использовать 32-битные целые числа со знаком при синтаксическом анализе даты. Такая реализация была бы глупой. Неважно, какой формат вы выберете, вы не можете защититься от глупости - и ISO8601 здесь не поможет, потому что, хотя это может быть то, что появляется в сети, каждая отдельная реализация будет анализировать его за определенное количество раз. единиц с какой-то эпохи, так как все компьютеры работают с датами, и это единственный способ практически выполнять вычисления, такие как срок действия токена. Следовательно, каждая реализация, даже при использовании ISO8601, восприимчива к выбору числового представления с низкой точностью для обработки дат после определенного времени,включая выбор 32-битных целых чисел со знаком для представления даты в секундах с 1970 года, как в случае проблемы Y2038. Каждая реализация должна выбрать тип числа подходящего размера для представления их проанализированных дат, что вы, вероятно, обнаружите, что все они это делают (а если нет, вы должны сообщить об ошибке).
Итак, нет ничего плохого в том, что JWT используют секунды с эпохи UNIX для дат.
Временные метки Unix не так уж и плохи - они определенно помогут вам упростить кучу вычислений, а не разбирать дату.
В большинстве случаев претензии по дате в JWT должны сравниваться с NOW() (подумайте о exp утверждение), поэтому имеет смысл использовать там отметки времени.
Я не стал бы беспокоиться об ошибке Y2038, поскольку 32-битная система будет иметь большие проблемы, чем выпуск JWT.