如何使用withCredentials解码发送的凭据:从角度为true，发送和接收的cookie没有相同的令牌 [英] How to decode credentials sent using withCredentials: true from angular, cookie sent and received don't have the same token

问题描述

我有一个python后端，在其中创建一个httponly cookie并将其发送到有角度的前端.

I've a python back end, where I create an httponly cookie and send it to angular front end.

后端的cookie是这样创建的:

The cookie in the back end is created like this:

...
token_session = request.create_jwt_token(1, data=<userdata>, permissions=...)
...
response.set_cookie(name='token', value=token_session, secure=False, httponly=True)

在Visual Studio代码中，我看到请求的类型为:

In Visual studio code, I see that request is of type:

类型(请求):< class'pyramid.util.Request'>

在前端，我在浏览器 Application TAB (chrome开发工具，然后是Storage，Cookies部分)中正确看到了cookie，并带有名称和值:

In the front end, I see the cookie correctly in the browser Application TAB (chrome dev tools, then Storage, Cookies section), with name and value:

name: token and value: eyJ0eXAiOiJKV...

但是现在从角度来看，当我使用get请求并使用等于或等于 true 的 withCredentials 调用后端时，如下所示:

But now from angular when I call the back end using a get request and with withCredentials equal to true like this:

this.http.get(back_end_url, {responseType: 'json', withCredentials: true})...

然后在后端，我看到一个具有不同名称(名称=会话)的cookie

In the back end then, I see a cookie with different name ( name = session)

和另一个等于:

request.cookies :<具有值{'session':'ivc9aeSKo1JuwJ12xfVHnXcxUD4Cc6o8Kfy07-dxTif8C-EAxk1sbxKH1STNUu-3n7csFHlwe7SU3MJY-d1pOoQC

request.cookies: <RequestCookies (dict-like) with values {'session': 'ivc9aeSKo1JuwJ12xfVHnXcxUD4Cc6o8Kfy07-dxTif8C-EAxk1sbxKH1STNUu-3n7csFHlwe7SU3MJY-d1pOoQC

后端:(python)

@view_config(route_name='is_logged', renderer="json")
    def is_logged_view(request):
        if request.cookies:
            print ("cookie: ", request.cookies.get("session"))

在第一部分中创建的jwt令牌中，我看到两个点，但是在对后端的响应中，我看不到任何两个点，这非常奇怪...

In the jwt token created in the first part I see two dots, but in the response to the back end I don't see any such 2 dots, it's very weired ...

选项 secure = False 是因为我在localhost中尝试此操作，并且在创建cookie时也未提供 domain 参数.

The option secure=False is because I'm trying this in localhost and I did not provide The domain param as well when the cookie was created.

我的问题:

chrome是否没有理由不向后端发送相同名称的相同cookie?或是否有任何特定的编码或格式?

我已经尝试使用以下方法解码 session 令牌值:

I already tried to decode the session token value using this: how-to-decode-base64-url-in-python, but I'm not able to get the original jwt generated token in the back end.

在将httponly cookie附加到httpclient请求以对cookie或令牌值进行编码时，浏览器是否使用任何特定算法?

Is there any specific algorithm used by a browser when appending httponly cookie to an httpclient request to encode cookie or token value ?

此RFC https://tools.ietf.org/html/rfc6265#section-5.4 提供了一些有关如何将cookie序列化为cookie字符串的提示，但没有明确引用cookie的编码方式:

This RFC https://tools.ietf.org/html/rfc6265#section-5.4 provide some hint about how to Serialize the cookie into a cookie-string, but no explicit reference to the way that the cookie is encoded:

5.4.  The Cookie Header

   The user agent includes stored cookies in the Cookie HTTP request
   header.

   When the user agent generates an HTTP request, the user agent MUST
   NOT attach more than one Cookie header field.

   A user agent MAY omit the Cookie header in its entirety.  For
   example, the user agent might wish to block sending cookies during
   "third-party" requests from setting cookies (see Section 7.1).

   If the user agent does attach a Cookie header field to an HTTP
   request, the user agent MUST send the cookie-string (defined below)
   as the value of the header field.

   The user agent MUST use an algorithm equivalent to the following
   algorithm to compute the "cookie-string" from a cookie store and a
   request-uri:

   1.  Let cookie-list be the set of cookies from the cookie store that
       meets all of the following requirements:

       *  Either:

             The cookie's host-only-flag is true and the canonicalized
             request-host is identical to the cookie's domain.

          Or:

             The cookie's host-only-flag is false and the canonicalized
             request-host domain-matches the cookie's domain.

       *  The request-uri's path path-matches the cookie's path.

       *  If the cookie's secure-only-flag is true, then the request-
          uri's scheme must denote a "secure" protocol (as defined by
          the user agent).

             NOTE: The notion of a "secure" protocol is not defined by
             this document.  Typically, user agents consider a protocol
             secure if the protocol makes use of transport-layer
             

         security, such as SSL or TLS.  For example, most user
         agents consider "https" to be a scheme that denotes a
         secure protocol.

   *  If the cookie's http-only-flag is true, then exclude the
      cookie if the cookie-string is being generated for a "non-
      HTTP" API (as defined by the user agent).

   2.  The user agent SHOULD sort the cookie-list in the following
       order:

       *  Cookies with longer paths are listed before cookies with
          shorter paths.

       *  Among cookies that have equal-length path fields, cookies with
          earlier creation-times are listed before cookies with later
          creation-times.

       NOTE: Not all user agents sort the cookie-list in this order, but
       this order reflects common practice when this document was
       written, and, historically, there have been servers that
       (erroneously) depended on this order.

   3.  Update the last-access-time of each cookie in the cookie-list to
       the current date and time.

   4.  Serialize the cookie-list into a cookie-string by processing each
       cookie in the cookie-list in order:

       1.  Output the cookie's name, the %x3D ("=") character, and the
           cookie's value.

       2.  If there is an unprocessed cookie in the cookie-list, output
           the characters %x3B and %x20 ("; ").

   NOTE: Despite its name, the cookie-string is actually a sequence of
   octets, not a sequence of characters.  To convert the cookie-string
   (or components thereof) into a sequence of characters (e.g., for
   presentation to the user), the user agent might wish to try using the
   UTF-8 character encoding [RFC3629] to decode the octet sequence.
   This decoding might fail, however, because not every sequence of
   octets is valid UTF-8.

推荐答案

我认为问题在于浏览器正在将您的数据转换为字节格式，您需要在rxjs中使用Behavioursubject概念并为该凭证创建模型

I think the issue is the browser is converting your data into byte format u need to use Behavioursubject concept in rxjs and create a model for that credentials

这篇关于如何使用withCredentials解码发送的凭据:从角度为true，发送和接收的cookie没有相同的令牌的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！