Support for multiple cookies with the same name from different domains

[jwalton]

Let's say you have a website at "foo.server.com", and you set a cookie called "session" with the domain "foo.server.com". Then you set a second cookie called "session" with the domain ".server.com". You might expect one cookie to overwrite the other, but actually what happens is the browser will send you both cookies. It seems like cookies right now can only parse the first one, but there are use cases where you want to retrieve both of them.

const request = {headers: {cookie: "foo=bar; foo=baz"}};
cookies = new Cookies(request, null, {});
cookies.get('foo'); // Returns 'bar', but what happened to 'baz'?

[dougwilson]

Yes, it currently only returns one. Please feel free to submit a pull request implementing the feature you're looking for! If you're not sure where to start, let us know and also feel free to describe what you think your implementation could be if you're not sure and need help on that :)

[jwalton]

Well, the obvious API would be to return an array if there's more than one... But this is terrible from a "breaking the API" perspective. You could add a {multi: true} flag in the get options?

Although I'm debating if it's easier to submit a PR or just rename this second cookie. :P

[jwalton]

I also have no idea how signed cookies would work here. I'd guess you'd have to check the cookie against every signature?

[dougwilson]

Yea, an array is obvious, though an API that sometimes returns an array and sometimes a string, with that being completely controlled by an untrusted party usually ends badly, so would like to really have an API that only returns one or only returns an array (even if it's just an array of one). The multi: true idea could be that, always returning an array when that is set, even if there is only one cookie.

One problem is I'm not sure how the key rotation will work with this, since when the key is getting updated, it needs to set the new .sig cookie with the matching properties so the browser accepts is. I assume that you'd also need to specific an array of the other options as well so they all set right? I'm not sure if there is a spec that says if the cookies will appear in any particular order to identify which is from which domain.

[dougwilson]

So the cookies are already checked against every signature, the purpose is key rotation. Then when the cookie is using an outdated key, the new .sig cookie is set (sorry, my post above missed your question, so this is just an extension for that part of the question that the above doesn't answer).

[jwalton]

RFC 6265 says:

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.

Which is... the opposite of helpful. :) Although this RFC makes no mention of signed cookies, and a quick five minutes of googling hasn't found me an RFC that does.

[dougwilson]

Signed cookies here isn't going to be an RFC. How it works is that this module always sets two cookies: one is {name} and the other is {name}.sig, where the latter contains the hmac of the first.

[jwalton]

Oh, I see, the signature is a custom thing. Yeah, so you can't rely on order - you just have to check them all. And yes, key rotation is going to be painful. :P You would need to set the cookie with the same domain and path, or else you risk blowing away the wrong signature. And since these aren't included in what's passed in, there's no way to know them. I think you're existing signature implementation is broken if you're setting domains, though, because key rotation always sets a cookie with no domain. In the single "get" case, you can pass the same options to `get` as you pass to `set`, and then so long as the keys from different domains are signed with different keys, it'll work out. I don't think there's a sensible way to do multi-get here.

[ivan-demchenko]

@jwalton @dougwilson But what about the domains? Both foo.server.com and .server.com set session cookies. Those cookies must have different domains then, mustn't they?

[jwalton]

@raqystyle yes, exactly - one has the "foo.server.com" domain, and one has the ".server.com" domain (meaning it's sent to any server in *.server.com). Unfortunately, the client doesn't bother to send the domain the cookie was set for in the request.

[osdiab]

I'm having a related problem - I want to clear a particular cookie key both for an unspecified domain and a specified domain at the same time, but I'm finding that this library will not actually create set-cookie expiration header fields if you call set() twice, once with a domain and once without; so then I tried just creating the headers myself (in koa), but when the headers get flushed to the response it doesn't seem to be resulting in both headers present in the response (which might not be~~ is not an issue with this library, found that my headers are being overwritten by koa-session's autoCommit feature), so a little stuck!