客户端向服务器发送承载令牌,如下所示:
Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
显然,我不需要“承载者”前缀,所以我必须去掉它。我知道这很简单,只需拆分字符串并使用正确的元素,但我不明白的是,为什么我使用的库函数不适合我。 我还需要检查令牌的类型是否正确(在本例中是bearer)。它迫使我写额外的代码行,我不喜欢它。在
所以我的问题是“有没有更聪明的方法来处理代币?”在
我正在使用PyJWT
。在
Bearer ...
字符串通常在HTTP请求的Authorisation
头中找到。然后,它取决于您用来接收或发送HTTP请求的特定框架(如果有对此类头的特定支持)。在格式不是JSON web令牌标准的一部分;},都是一个很常见的地方,但是像PyJWT这样的包只处理令牌,而不处理传输机制。因此,一个专注于处理JSON Web令牌的库不应该期望处理HTTP报头之外的解析令牌(尽管有些库可能会这样做)。在
Authorization
报头,无论是否有{HTTP 1.1规范确定了HTTP请求的头应该是什么样子,它只标准化了^{} header in a request 应该包含凭证,而separate RFC 2617 standard on HTTP Authentication则规定凭证至少应包含一个方案和任意参数:
对于pythonhttp库来说,这并不是什么好东西。具体的RFC只进一步指定了两种不同的授权方案:Basic和Digest。承载物不属于本标准的一部分。因此,像Werkzeug(支持Flask等)这样的框架确实支持解析} class docs )。在
Authorization
头,但前提是使用了这两个标准化方案中的一个(参见^{Bearer
方案是OAuth 2.0 standard的一部分。它只是定义客户机可以发送一个令牌,一个给他们的令牌,服务器可以接受这个令牌来授权请求。Bearer
方案只是发送令牌的几种方法之一,对令牌的唯一限制是它应该是base64编码的。什么也没说。在但它确实指出,如果使用授权头,则格式必须follow a specific format:
^{pr2}$因此}作为结尾的填充,因此}在这里是多余的)。就这样。在
Bearer
,后跟1个或多个空格,然后后跟Base64数据,并添加一些允许的字符(Base64只使用字母、数字和+
和{-
、.
、_
和{如果必须有一个库,请找到一个处理OAuth 2.0的库。但在其他方面,只在空白上拆分并(可选地)将字符串解码为Base64:
现在,}要么是{},要么是{}之后的第一个非空白部分,以及该字符串的base64解码版本。在
b64token
和{JSON Web令牌实际上是三个用
.
连接的Base64编码的字符串,因此将此类令牌解码为单个Base64编码值很容易失败。将b64token
字符串传递给PyJWT
。在相关问题 更多 >
编程相关推荐