Cannot set cookies with domain localhost

[lfdebrux]

When using option rejectPublicSuffixes: true (the default), trying to set a cookie with Domain=localhost throws the error Cookie has domain set to a public suffix, which I believe is incorrect.

How to reproduce

Run the following code with the latest master of tough-cookie (commit 1b25269)

const { CookieJar } = require("../lib/cookie");
const cookieJar = new CookieJar();
cookieJar.setCookieSync("a=b; Domain=localhost", "http://localhost")  // throws 'Error: Cookie has domain set to a public suffix'

Expected result

I can set cookies with Domain=localhost without an error.

Workaround

Turning off the rejectPublicSuffixes option when creating the CookieJar causes the cookie to be set without errors, as expected.

[awaterma]

We're not seeing localhost on the main suffix list: https://publicsuffix.org/list/public_suffix_list.dat

However, localhost is a special case domain: https://datatracker.ietf.org/doc/rfc6761/

We are thinking of just updating the error in this case; but I'll let @ruoho-sfdc comment further.

[medelibero-sfdc]

Hi @lfdebrux,

I just tried to recreate this issue with the following code but I was not able to.

const jar = new tough.CookieJar(); jar.setCookieSync("a=b; Domain=localhost", "http://localhost")

What am I doing wrong? It looks like the same code? If you try this against the master branch are you able to reproduce the problem?

Thanks,
Mike

[lfdebrux]

Hi @medelibero-sfdc,

I'm not sure why your setup isn't raising the error... if I checkout the current version of the master branch and run your snippet I do get the error 🤔

tough-cookie at 09:15:09 
% node -e 'const tough = require("."); const jar = new tough.CookieJar(); jar.setCookieSync("a=b; Domain=localhost", "http://localhost")'
/Users/laurencedebruxelles/Code/tough-cookie/lib/cookie.js:1714
      throw syncErr;
      ^

Error: Cookie has domain set to a public suffix
    at CookieJar.setCookie (/Users/laurencedebruxelles/Code/tough-cookie/lib/cookie.js:1172:15)
    at CookieJar.setCookie (/Users/laurencedebruxelles/Code/tough-cookie/node_modules/universalify/index.js:5:67)
    at CookieJar.setCookieSync (/Users/laurencedebruxelles/Code/tough-cookie/lib/cookie.js:1708:21)
    at [eval]:1:68
    at Script.runInThisContext (vm.js:134:12)
    at Object.runInThisContext (vm.js:310:38)
    at internal/process/execution.js:81:19
    at [eval]-wrapper:6:22
    at evalScript (internal/process/execution.js:80:60)
    at internal/main/eval_string.js:27:3

[awaterma]

@ifdebrux -- could you also kindly let us know what version of NodeJS you are testing with?

[lfdebrux]

@awaterma I tested with Node 12 (v12.22.6), Node 14 (v14.17.6), and Node 16 (v16.11.0). All versions produced the same error.

[awaterma]

@ifdebrux -- I can reproduce this now in a vows unit test. I'll look into the issue a bit further and see if I can propose a fix.

.addBatch({
    "setCookie with localhost (GH-215)": {
      topic: function() {
        const cookieJar = new CookieJar();
        return cookieJar.setCookieSync("a=b; Domain=localhost", "http://localhost")  // should throw 'Error: Cookie has domain set to a public suffix'
      },
      works: function(c) {
        assert.instanceOf(c, Cookie)
      }
    }
  })

Result:

setCookie with localhost (GH-215) 
      ✗ works 
        » An unexpected error was caught: Error: Cookie has domain set to a public suffix 
      at CookieJar.setCookie (/home/cookie/lib/cookie.js:1172:15) 
      at CookieJar.setCookie (/home/cookie/node_modules/universalify/index.js:5:67) 
      at CookieJar.setCookieSync (/home/cookie/lib/cookie.js:1708:21) 
      at Object.topic (/home/cookie/test/regression_test.js:195:26) 
      at run (/home/cookie/node_modules/vows/lib/vows/suite.js:133:35) 
      ....

[awaterma]

I've looked into the RFCs for this; and I think our current behavior is acceptable. localhost is a special domain, but its behavior in cookies, as a site domain, doesn't seem well defined, as far as I can tell. Please see: https://datatracker.ietf.org/doc/html/rfc6761#section-6.3 and https://datatracker.ietf.org/doc/html/rfc6265#section-5.2.3. In our case, we do allow ".localhost" as a special domain, per 6761, but choose to treat "localhost" as a Public Suffix. You can work around this in several ways, as the following tests show:

.addBatch({
    "setCookie with localhost (GH-215)": {
      topic: function() {
        const cookieJar = new CookieJar();
        return cookieJar.setCookieSync("a=b; Domain=", "http://localhost")  // when domain set to 'localhost', will throw 'Error: Cookie has domain set to a public suffix'
      },
      works: function(c) {
        assert.instanceOf(c, Cookie)
      }
    }},
    { 
      "setCookie with localhost (localhost.local domain)": {
        topic: function() {
        const cookieJar = new CookieJar();
        return cookieJar.setCookieSync("a=b; Domain=localhost.local", "http://localhost")
      },
      works: function(c) {
        assert.instanceOf(c, Cookie)
      }
    }},
    { 
      "setCookie with localhost (.localhost domain)": {
        topic: function() {
        const cookieJar = new CookieJar();
        return cookieJar.setCookieSync("a=b; Domain=.localhost", "http://localhost")
      },
      works: function(c) {
        assert.instanceOf(c, Cookie)
      }
    }
  })

There is also some discussion on the following thread, which also speaks to how several browsers handle the issue: https://stackoverflow.com/questions/1134290/cookies-on-localhost-with-explicit-domain

And there are similar issues filed with other cookie based projects, for example:

• how to set a cookie for localhost in chrome ? js-cookie/js-cookie#247
• https://bugs.chromium.org/p/chromium/issues/detail?id=56211

I'll use this work item to check in the test updates; so you and others at least have a direction to go with local cookie development.

If you can build an argument from the RFCs that show that we have taken the wrong approach; we'll gladly reconsider!

Pull requests and accompanying tests really help us move along issues! Please take a look at the sample above, discussion links and let us know your thoughts.

[awaterma]

@miggs125 helped us with our implementation in issue #160, for special use domains. He may have some thoughts to contribute to this thread.