This happens when I parse a cookie string that has an 'HttpOnly' attribute. I usually use it along with Secure attribute.

Here are the specifications for the HttpOnly attribute: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#restrict_access_to_cookies

JS libraries like cookie has the option to set HttpOnly to some cookies. We need to patch it. Thank you.

Hi,
we are going to include your module in Debian and Ubuntu.

But we have some problem here.. our automatic systems check for tags in github when look for a new release.

It seems you do not provide a tag for version 1.3.2. Could you please make it? and use them in the future?

Thanks in advance.

L.

Found a bug that only happens sporadically: TypeError: access_info.domain.replace is not a function

See attached screenshot

For some reason access_info.domain is a cookieAccessInfo instead of a plain string, causing the problem.

exports.CookieAccessInfo=CookieAccessInfo=function CookieAccessInfo(domain,path,secure,script) {

this will add CookieAccessInfo to the global namespace!

var CookieAccessInfo=exports.CookieAccessInfo=function CookieAccessInfo(domain,path,secure,script) {

this is the way to go man.

I don't have time to PR the changes sorry.

See npm/npm#3059 - prepublish also runs during npm install inside package's folder, so essentially every time someone clones from git, and runs npm install so they can dev, they get an error, like so:

> [email protected] prepublish /Users/dominykas/devel/experiments/tmp/node-cookiejar
> jshint cookiejar.js && git tag $npm_package_version && git push origin master && git push origin --tags

fatal: tag '2.0.3' already exists

You can use in-publish to circumvent this: https://www.npmjs.com/package/in-publish

For CookieAccessInfo.All I'd expect to get all the well-formed cookies, even the expired ones.

Use cases:

• The package is used in test frameworks like chai and this makes it impossible to test for expired cookies.
• Also using the jar to collect cookies for response, this makes it impossible to explicitly send a 'clear cookies' response as they are not added to the jar.

Hi there. Unfortunately I can't package your module without knowing the license, so from a distribution packaging point of view it would be great if you could clarify this. Including a copy of your chosen license (eg, MIT) in a file called LICENSE would also be very helpful.

Thanks!

Hi,

I'm using cookiejar as part of the popular scraping package x-ray. For some links, cookiejar will break with an error TypeError: Cannot read property '1' of null with the stack trace referring to https://github.com/bmeck/node-cookiejar/blob/master/cookiejar.js#L72. It breaks even when used within a try/except block so I can't do much to prevent this problem in my code. Can you give me some advice on how to fix this issue or help me make cookiejar throw a relevant error that I can catch downstream?

There's a reproducible example here:
matthewmueller/x-ray#234

Hi!

This project is a dependency of Faye, and right now, the Mocha test suite is reporting global leaks because of cookiejar. It looks like these issues were fixed a year ago in this commit (4ecfd5d).

Would you please bump the version and get it on NPM?

Thanks!

It would be great if releases would not just bump the version in package.json, but also have an associated tag in git for them. This would make reviewing changes a lot nicer, and improve also the information provided by automated systems such as dependabot.

It seems that there are some tags already, but not for all versions. Maybe the release procedure could include making the tag, possibly by using npm version (patch|minor|major) instead of manually touching package.json?

If the cookie's value contains an equal sign, it will be URL-encoded:

sample=e30%3D; Path=/

This library should decode the value as part of parsing.

Looking to make a PR to superagent w/ an updated version that includes the latest fixes.

I am getting this error when using jar.setCookie("cookiestr")
i dont get it

Although the specs are ambiguous about this (RFC-2965: HTTP State Management Mechanism, Google's Browser Security Handbook, or google), common browsers (I tested on Safari 5, Chrome 22, Firefox 10 on Mac) are considering a cookie from host with no port definition to be applicable for any port on the same host. This is true for the two different situations:

1. a cookie that was received with no port should match on any specific port.
2. a general cookie (.something.com) should match on any port

Because of the ambivalence in the specs, perhaps we should add a configurable flag for choosing the behavior (different ports = different cookie vs. different ports = same cookie).

In any case, for a site (http://www.something.com:80) running on port 80, a specific cookie on port 80 (www.something.com:80) should behave just like a specific cookie with no port (www.something.com), which is similar to a general cookie (.something.com) and vice versus.

A small change in collidesWith() is required for this. I would love to code the fix and make a pull request.

Hey, can you please npm publish issue #6 is plaguing me in superagent and I can't nag them to update until you publish.

on same cookie name in diff domain
only return one cookie in same name

Hi,

SuperAgent npm package depends of 2.0.0 node-cookiejar.
When I look on the repo seems that version 2.0.0 is pretty stable right now.

Do you thing will be possible to publish the 2.0.0 version on npm registry?

Hey @bmeck, thanks for the awesome project! We use it inside of the chai-http plugin and it works great!

One thing that would be really useful for our users - given that chai-http is a test framework - is to get cookies irrespective of access settings (See this issue for more). Perhaps having a sentinel of Cookie.CookieAccessInfo.All could be used to flag to cookie.match() to automatically return true?

Any thoughts on this would be much appreciated. If you like the idea I'm happy to PR it 😄

Hi,

Can you publish a new release of cookiejar on npm and tag it please ?

Thanks

The SameSite attribute is not handled by the package at all.