Cookies

[wesleytodd]

whatwg/html#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.