dlang-requests icon indicating copy to clipboard operation
dlang-requests copied to clipboard

Wrong cookie handling

Open Domain opened this issue 6 years ago • 5 comments

If the domain value of a cookie does not start with a . it will be added by the client. A cookie will be overwritten (or deleted) by a subsequent cookie exactly matching the name, path and domain of the original cookie.

How do browser cookie domains work? How to handle multiple cookies with the same name?

Domain avatar Nov 01 '17 08:11 Domain

Hello @Domain,

Thanks for report, will look a bit later.

ikod avatar Nov 01 '17 08:11 ikod

Hello @Domain

set-cookie processed in https://github.com/ikod/dlang-requests/blob/master/source/requests/http.d#L631 and as far as I can see it breaks https://tools.ietf.org/html/rfc6265#section-5.2.3 in that it do not strip leading dot away.

5.2.3.  The Domain Attribute

   If the attribute-name case-insensitively matches the string "Domain",
   the user agent MUST process the cookie-av as follows.

   If the attribute-value is empty, the behavior is undefined.  However,
   the user agent SHOULD ignore the cookie-av entirely.

   If the first character of the attribute-value string is %x2E ("."):

      Let cookie-domain be the attribute-value without the leading %x2E
      (".") character.

   Otherwise:

      Let cookie-domain be the entire attribute-value.

   Convert the cookie-domain to lower case.

   Append an attribute to the cookie-attribute-list with an attribute-
   name of Domain and an attribute-value of cookie-domain.

Then, when we build headers for next request https://github.com/ikod/dlang-requests/blob/master/source/requests/http.d#L493 I just follows rules from RFC.

Can you, please, give me example of wrong request processing, so that I can find where exactly problem is.

Thanks

ikod avatar Nov 01 '17 18:11 ikod

@ikod According to https://tools.ietf.org/html/rfc6265#section-5.1.3

5.1.3.  Domain Matching

   A string domain-matches a given domain string if at least one of the
   following conditions hold:

   o  The domain string and the string are identical.  (Note that both
      the domain string and the string will have been canonicalized to
      lower case at this point.)

   o  All of the following conditions hold:

      *  The domain string is a suffix of the string.

      *  The last character of the string that is not included in the
         domain string is a %x2E (".") character.

      *  The string is a host name (i.e., not an IP address).

So "x.example.com" matches "example.com" Your implementation is followed RFC2965, not RFC6265 https://github.com/ikod/dlang-requests/blob/master/source/requests/utils.d#L113

See also: https://www.mxsasha.eu/blog/2014/03/04/definitive-guide-to-cookie-domains/

Domain avatar Nov 02 '17 03:11 Domain

A cookie will be overwritten (or deleted) by a subsequent cookie exactly matching the name, path and domain of the original cookie. https://tools.ietf.org/html/rfc6265#section-5.3

   11.  If the cookie store contains a cookie with the same name,
        domain, and path as the newly created cookie:

        1.  Let old-cookie be the existing cookie with the same name,
            domain, and path as the newly created cookie.  (Notice that
            this algorithm maintains the invariant that there is at most
            one such cookie.)

        2.  If the newly created cookie was received from a "non-HTTP"
            API and the old-cookie's http-only-flag is set, abort these
            steps and ignore the newly created cookie entirely.

        3.  Update the creation-time of the newly created cookie to
            match the creation-time of the old-cookie.

        4.  Remove the old-cookie from the cookie store.

   12.  Insert the newly created cookie into the cookie store.

Now the new cookie is just appended to the end. https://github.com/ikod/dlang-requests/blob/master/source/requests/http.d#L631

Domain avatar Nov 02 '17 03:11 Domain

@Domain I see, this should be fixed. It will take some time.

ikod avatar Nov 02 '17 17:11 ikod