我找到了TimedJSONWebSignatureSerializer和URLSafeTimedSerializer。我想知道为什么这两种方法存在。作为该库的用户，选择一个或另一个的原因是什么？
我什至没有在 docs 中找到TimedJSONWebSignatureSerializer，但只有something general about JSON Web Signatures。
查看继承力没有帮助：
TimedJSONWebSignatureSerializer继承自JSONWebSignatureSerializer URLSafeTimedSerializer继承自URLSafeSerializerMixin，TimedSerializer 看着构造函数，我的印象是两者可能都适用于相同的用例，但也许JSON Web签名是标准化的，而另一个不是吗？
查看用法：
from itsdangerous import TimedJSONWebSignatureSerializer, URLSafeTimedSerializer
data = {"id": 42, "op": "foobar"}
max_age_s = 123
s1 = TimedJSONWebSignatureSerializer('secret', expires_in=max_age_s)
s1_dumped = s1.dumps(data)
s1_loaded = s1.loads(s1_dumped)
s2 = URLSafeTimedSerializer('secret')
s2_dumped = s2.dumps(data)
s2_loaded = s2.loads(s2_dumped, max_age=max_age_s)
然后
>>> s1_dumped
b'eyJhbGciOiJIUzUxMiIsImlhdCI6MTU2MTEwNDU0NSwiZXhwIjoxNTYxMTA4MTQ1fQ.eyJpZCI6NDIsIm9wIjoiZm9vYmFyIn0.sux9j4OpBc7-se16WSrZvp-bll5ZeyCQR_CumSE7jPQ9-w_kTqpr0OtwhJp8S766Xt1W3fKSE-dl2z8q9ZAhzg'
>>> s2_dumped
'eyJpZCI6NDIsIm9wIjoiZm9vYmFyIn0.XQyQoQ.-6n5Jw6TWz8tsyfgagyS5_fHjAY'
>>> len(s1_dumped)
185
>>> len(s2_dumped)
66
因此，JSON Web签名的时间更长。拥有它会赢得什么？
答案 0 :(得分：0)
我的印象是两者可能都适用于相同的用例 但是也许JSON Web签名是标准化的，而另一个不是吗？
这两种方法的用例几乎相同，但是当您使用URLSafeTimedSerializer而TimedJSONWebSignatureSerializer更灵活时，则不需要额外的编程步骤，就需要在双方（发送者和接收者）处都具有Itsangerous库。 ，因为JSON Web签名格式为standardized。这扩展了用例
TimedJSONWebSignatureSerializer与其他语言编写的软件进行通信，因为它基于JSON格式，并且有libs available for many different languages。
实际上，JSON Web签名和JSON Web Tokens通常被用作授权令牌，但不限于该用例。
示例的不同结果有两个原因：
JSON Web签名格式需要标头和有效负载部分，它们均是JSON格式，并且标头还包含强制性alg claim，即
标识用于保护JWS的加密算法。
这两种方法对签名使用不同的加密算法：
URLSafeTimedSerializer默认使用SHA1
内部危险使用HMAC和SHA1（according to the docs）
TimedJSONWebSignatureSerializer使用SHA512时，请参见解码后的标头：
{ “ alg”：“ HS512”， “ iat”：1561104545， “ exp”：1561108145 }
后者更长，但也更安全。 （see SHA1 vs. SHA256）
我希望这能解释这些方法的不同用例和结果。
顺便说一句。在标头中看到iat（在发出）和exp（在到期）声明是“有趣的”，以前从未见过。通常它们是有效载荷的一部分。
这就提出了一个问题，如果想要JWS / JWT输出，为什么还要使用Itsdangerous，因为还有很多其他可用的库，也可以用于python。