Cookies

[wesleytodd]

https://github.com/whatwg/html/issues/9935

Just wanted to add this here as we would likely want to follow and inform this proposal to make sure it is suitable for node. Would be good to discuss this when we spin up the new series of meetings for this group.

[kettanaito]

Thanks for mentioning this, @wesleytodd! Please, feel free to ping me regarding any meetings (granted they are public), I would love to participate and help out with what I can.

[wesleytodd]

Cool, we are just starting an effort to bring this group back to life. It would be awesome if you are able to participate, open to everyone, and especially if we can land on a great api for node core which could also replace all the userland framework libraries which the frameworks currently support.

[kettanaito]

especially if we can land on a great api for node core which could also replace all the userland framework libraries which the frameworks currently support.

That's precisely the intention—to solve userland problems. I can analyze various frameworks and how they educate their users to work with cookies and prepare a list of sorts for the first meeting. That'd be a fun exercise.

Let's see what the WHATWG community has to say regarding the proposal. I wouldn't want to rush things without a proper discussion first.

[arei]

Worth noting that we discussed a similar topic when this group was first spinning up: #32

[wesleytodd]

Thanks @arei I knew that rung a bell but for some when I browsed the issues I must have missed that one. Maybe we close this one in favor of that and reopen is since it was not actually finished in the tech plan?

[arei]

@wesleytodd kind of in favor of closing the older one and keeping this one to move forward.

[ljharb]

How can a cookies API make sense for "not a browser"?

[kettanaito]

@ljharb, you can use the proposed Cookie API in server-side frameworks to create cookies you set on the Response instance. Here's an example:

server.post('/login', ({ request }) => {
  const sessionCookie = new Cookie('sessionId', createSessionId(), {
    expires: Date.now() + day,
    httpOnly: true,
    secure: true,
  })

  return new Response(null, {
    headers: {
      'Set-Cookie': sessionCookie.toString()
    }
  })
})

You can also use the said API to handle request cookies for scenarios like authentication:

server.get('/protected/resource', ({ request }) => {
  const cookies = Cookie.from(request.headers.get('Cookie'))

  if (!cookies.has('sessionId')) {
    return new Response(null, { status: 403 })
  }

  return new Response('Hello world')
})

Granted, the current Cookie proposal doesn't account for multi-value cookie strings. This is where a discussion is much appreciated. Perhaps Cookie.from() should return a Map<string, Cookie> instead of a single cookie instance.

You can also use this API in Node.js in general, like in automated testing.

[wesleytodd]

@ljharb:

https://github.com/pillarjs/cookies 7.9m downloads/M https://github.com/jshttp/cookie 203m downloads/M

[dougwilson]

There was some older Cookie API I saw on MDN I was planning to implement in the jshttp/pillarjs modules. Not sure if this is different or not, but I can take a look.

[wesleytodd]

Hey @dougwilson long time no see! I am guessing you mean this one? https://developer.mozilla.org/en-US/docs/Web/API/CookieStore

We probably need to make a list of the use cases we need to support and see where the overlap is with the existing apis.

[dougwilson]

Yea, that's it. I haven't done anything yet, so happy to follow along. It didn't seem perfect fit for server side anyway, but it was at least something at the time, haha. I still read all this stuff and try to chim in when I can :)

[wesleytodd]

Yeah, I agree it is not a perfect fit. One of my original goals with this group was to see what we could pull out of ecosystem libs to standardize in node core, so I don't think this should stop you from making progress on it in the jshttp/pillarjs modules, but I would expect we end with opening a PR to node with whatever we land on.

[ljharb]

ahhh ok, if it's an API exclusively for webserver use then that makes perfect sense.

[wesleytodd]

I am not sure that "exclusively" is the goal. I don't want to speak for @kettanaito, but IMO we have found that users want similar apis even if they cannot be 100% identical across their server/client code. To me, the goal of us being involved in any browser spec would be to ensure it doesn't go the way of ESM and become a huge battle for the future.

[ljharb]

I would totally expect a similar API interface as what the browser has, ofc, but that doesn't mean it'd be 1:1 identical, nor does it mean it should be available under the same global/name.

[dougwilson]

@wesleytodd yea, I guess, would be nice to be in Node.js core itself. Cookies are very common thing to need.

[kettanaito]

I feel this is the right moment to mention that the API at question here won't immediately cover everything developers need to work with cookies. I'd like to see Cookie help folks parse and serialize cookie strings, while existing APIs like CookieStore can help achieve the set of other tasks (storing cookies).

I believe the expectations toward the proposed Cookie API are close identical to those for the cookie package that's widely used. It may even be a good idea to use that package as the implementation for the proposal itself, similar to how path-to-regexp was used to define and implement URLPattern. Learning from what developers have been using is the key.

[wesleytodd]

CookieStore can help achieve the set of other tasks (storing cookies).

Yeah I agree, and I am frankly unsure if we want to take on the CookieStore api in core just yet. It is not super helpful unless it works with the http clients, and that is a larger task. We would likely want to land support in undici fetch first if we wanted to do that. But I think scoping to just the server aspect to start is good, and that really just needs the parse/seralize bits to be useful imo.