Django中如何处理时区相关安全风险？

本文共计3042个文字，预计阅读时间需要13分钟。

在开发国际化网站时，避免与时代脱节，通用CMS更胜一筹。毕竟，最终用户可能来自全球各地。Django在这方面表现出色，但许多资深的开发者可能仍觉得它有些过于复杂。

在开发国际化网站的时候，难免会与时区打交道，通用CMS更是如此，毕竟其潜在用户可能是来自于全球各地的。Django在时区这个问题上下了不少功夫，但是很多资深的开发者都有可能尚未完全屡清楚Django中各种时间的实际意义和使用方法，导致写出错误的代码；作为安全研究人员，时区问题也可能和一些安全问题挂钩，比如优惠券的过期时间、订单的下单与取消时间等，如果没有考虑时区问题，有可能将导致一些逻辑漏洞。

本文就从多个常用模块开始，了解一下Django中的时区究竟是怎么回事，以及在时间的比较中可能出现的一些逻辑错误。

从“两种时间”说起

我们都知道，在Python中表示“时间”的对象是datetime.datetime。

其实在Python中，这个对象被分成了两个类型：

• aware datetime
• naive datetime

他们的区别是：如果datetime对象的tzinfo属性有设置时区值，则这个对象是一个aware datime；否则它是一个naive datetime。