Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cookie.parse ignores HttpOnly; Secure; #200

Open
gerhardcit opened this issue Oct 22, 2024 · 5 comments
Open

cookie.parse ignores HttpOnly; Secure; #200

gerhardcit opened this issue Oct 22, 2024 · 5 comments

Comments

@gerhardcit
Copy link

It seems that the parses wants key=value pairs and ignores the HttpOnly; Secure; settings?

import cookie from 'cookie';
const cookieStr = "MY_COOKIE=somevalue; Path=/; Expires=Tue, 29 Oct 2024 06:06:46 GMT; HttpOnly; Secure; SameSite=None";
const parsedCookie = cookie.parse(cookieStr, { decode: String });
console.log("parsedCookie", parsedCookie);

Result: (missing the HttpOnly and Secure settings?

parsedCookie C <[Object: null prototype] {}> {
  MY_COOKIE: 'somevalue',
  Path: '/',
  Expires: 'Tue, 29 Oct 2024 06:06:46 GMT',
  SameSite: 'None'
}

Expected result:

parsedCookie C <[Object: null prototype] {}> {
  MY_COOKIE: 'somevalue',
  Path: '/',
  Expires: 'Tue, 29 Oct 2024 06:06:46 GMT',
  HttpOnly: 'true',
  Secure: 'true',
  SameSite: 'None'
}

if the cookie value is explicit: HttpOnly=true; Secure=true

const cookieStr = "MY_COOKIE=somevalue; Path=/; Expires=Tue, 29 Oct 2024 06:06:46 GMT; HttpOnly=true; Secure=true;

then is parses correctly.

I tried 0.7.2 and 1.0.1. Am I missing something?

@gerhardcit
Copy link
Author

#164 seems to discuss this. Does not seem that there is a consensus about what to expect?

@blakeembrey
Copy link
Member

There is a consensus, this package doesn’t parse the Set-Cookie header, which is what you’re trying to do. It says this in the README too, parses a Cookie header.

This could be added as a feature, but it’s unsupported today.

@gerhardcit
Copy link
Author

@blakeembrey , thx.. duh!, you are very correct.
my source was this:

const setCookieHeaders = res.headers.getSetCookie();
for (const setCookieHeader of setCookieHeaders) {
....

We use it often in workers and sveltekit projects to pass a login method to my own upstream IDP and need to pass cookies (full or partly) on to the consumer, which has another hostname.

@blakeembrey
Copy link
Member

@gerhardcit Would it be helpful if this library did support parsing the set-cookie header? I'm happy to consider it as a new feature in the near future.

@gerhardcit
Copy link
Author

@blakeembrey , considering the amount of times that I intercept cookies from my own upstream servers in apps like sveltekit routes, (typically on cloudflare like serverless), i think it would be very useful.

  1. browser calls sveltekit route (www.myapp.com)
  2. sveltekit has to make a call to the upstream api (api.theapi.com). (need sending the cookies with, since the url changed
  3. it get's cookies back from api.theapi.com (with the set-cookie header)
  4. I need to: partly process, inspect, possibly modify and, send that on to the client on www.myapp.com.

Most of that is manual work since cookies are not passed through when urls changes, but often it needs to easily pass on (both are my apps after all, api.theapi.com serves various other myapps2... which are again sveltekit type apps where the api needs to go upstream.

Sveltekit documents this here: https://svelte.dev/docs/kit/@sveltejs-kit#Cookies
But when many urls and localhost http development are involved, I often find my self handle cookies more granular myself (as it might change name in the process)

Hopes this make sense and hopefully I'm not trying to reinvent some wheel which I have not seen of fully understand yet.

PS. in some cased I convert upstream cookies to some kind of encrypted response, since hybrid apps (ie Ionic wrapped with capacitor) and cookies is not great to work with, (even though there is a plugin for it) in which case I convert the incoming set-cookie from the upstream api to a encrypted jwt header and send that to the app client for later use.

So it would be very handy in my view.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants