Cookies with same name, but different subdomains not handled properly

[deejain]

When a site has two cookies with the same name, but different domains (e.g. cookie1 domain = .company.com, cookie2 domain = .app1.company.com), the following line within the CookiesService results in the first cookie in the list returned by document.cookie always being selected.

ngx-cookie/src/cookie.service.ts

Line 149 in 95d0994

if (isBlank((<any>lastCookies)[name])) {

The comment above that line of code...

          // the first value that is seen for a cookie is the most
          // specific one.  values for the same cookie name that
          // follow are for less specific paths.
          if (isBlank((<any>lastCookies)[name])) {
            (<any>lastCookies)[name] = safeDecodeURIComponent(cookie.substring(index + 1));
          }

... makes an invalid assumption. As per RFC6265 Section 4.2.2:

Although cookies are serialized linearly in the Cookie header,
servers SHOULD NOT rely upon the serialization order. In particular,
if the Cookie header contains two cookies with the same name (e.g.,
that were set with different Path or Domain attributes), servers
SHOULD NOT rely upon the order in which these cookies appear in the
header.

Certainly, on Chrome v66.0.3359.139, I've found that the assumption on Line 149 of CookiesService does not hold true. On Chrome, document.cookie provides the .company.com cookie before .app1.company.com.

The fact that this choice of order selection is hard-coded and hidden within this library can result in surprises to its users, like yours truly :).

On a side note, I've found this StackOverflow post to be helpful on this matter.

Since we must not rely on the cookie ordering, it would be best if this library makes it an explicit selection option that the user has to provide OR somehow determine the type of browser and do the right thing. I suspect the former is a saner and more maintainable approach.

Please note that I originally found this issue in the angular2-cookie library (see CookieService Line 130), which I now see has been deprecated. However, this same issue is also present in this new library. Therefore, I'm opening it here.

[frostme]

+1 on this. Having the same issue where cookie service is choosing the ".company.com" cookie instead of the ".app.compnay.com" . Because of this the wrong token, and thus wrong user is trying to be loaded, or in the case of the different environments, non existent users.