2

我发现TimedJSONWebSignatureSerializerURLSafeTimedSerializer。我想知道为什么存在这两种方法。作为该库的用户,选择其中一个的原因是什么?

我试过的

我什至没有TimedJSONWebSignatureSerializer文档中找到,但只有一些关于 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 签名要长得多。拥有它你会赢得什么?

4

1 回答 1

4

我的印象是两者可能适用于相同的用例,但 JSON Web 签名可能是标准化的,而另一个不是?

URLSafeTimedSerializer两种方法的用例几乎相同,但是不需要额外的编程步骤,在使用while的时候需要两边(发送方和接收方)的 Itsdangerous libTimedJSONWebSignatureSerializer更加灵活,因为 JSON Web Signature 格式是标准化的。这将用例扩展TimedJSONWebSignatureSerializer到与用其他语言编写的软件进行通信,因为它基于 JSON 格式,并且有许多不同语言的库可用

事实上,JSON Web Sigbnature 和JSON Web Tokens通常被用作授权令牌,但不限于该用例。

您的示例的不同结果有两个原因:

  • JSON Web Signature 格式需要一个 header 和一个 payload 部分,两者都是 JSON 格式,并且 header 还包含一个强制alg声明,其中

标识用于保护 JWS 的加密算法。

  • 这两种方法对签名使用不同的加密算法: URLSafeTimedSerializer默认使用 SHA1

在内部它的危险使用 HMAC 和 SHA1,(根据文档

TimedJSONWebSignatureSerializer使用 SHA512 时,请查看解码的标头:

{“alg”:“HS512”,“iat”:1561104545,“exp”:1561108145 }

后者更长,但也更安全。(参见 SHA1 与 SHA256

我希望这能解释这些方法的不同用例和结果。

顺便提一句。iat在标头中看到(issued at) 和(expires at) 声明是“有趣的” exp,以前从未见过。通常它们是有效载荷的一部分。这就提出了一个问题,如果您想要 JWS/JWT 输出,为什么要使用 Itsdangerous,因为还有许多其他库可用于此,也可用于 python。

于 2019-07-25T10:21:36.670 回答