2

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

我试过的

我什至没有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 回答