The package bourne that was introduced a short time ago breaks node versions 4.x.x as the rest operator is not supported in node 4.x.x without a flag.

/var/node/cthulhu/node_modules/bourne/lib/index.js:7
 exports.parse = function (text, ...args) {
                                 ^^^
SyntaxError: Unexpected token ...
  at exports.runInThisContext (vm.js:53:16)
  at Module._compile (module.js:373:25)
  at Object.Module._extensions..js (module.js:416:10)
  at Module.load (module.js:343:32)
  at Function.Module._load (module.js:300:12)
  at Function.cls_wrapMethod [as _load (/var/node/cthulhu/node_modules/newrelic/lib/shimmer.js:257:38)
  at Module.require (module.js:353:17)
  at require (internal/module.js:12:17)
  at Object.<anonymous> (/var/node/cthulhu/node_modules/statehood/lib/index.js:6:16)
  at Module._compile (module.js:409:26)
  at Object.Module._extensions..js (module.js:416:10)
  at Module.load (module.js:343:32)
  at Function.Module._load (module.js:300:12)
  at Function.cls_wrapMethod [as _load] (/var/node/cthulhu/node_modules/newrelic/lib/shimmer.js:257:38)
  at Module.require (module.js:353:17)
  at require (internal/module.js:12:17)
  at Object.<anonymous> (/var/node/cthulhu/node_modules/hapi/lib/connection.js:14:19)
  at Module._compile (module.js:409:26)
  at Object.Module._extensions..js (module.js:416:10)
  at Module.load (module.js:343:32)
  at Function.Module._load (module.js:300:12)
  at Function.cls_wrapMethod [as _load] (/var/node/cthulhu/node_modules/newrelic/lib/shimmer.js:257:38)

As talked about in #56 of hapi-auth-cookie (hapijs/cookie#56), cookies with a colon in their name are causing errors about invalid cookie values. I do not believe that colons are invalid in cookie names, hence this issue.

Allow cookie parsing to be turned off or ignore partially invalid chunks.

hapijs/hapi#3832, outmoded/discuss#727

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet.
We recommend using:

• CircleCI
• Travis CI
• Buildkite
• CodeShip
• Azure Pipelines
• TeamCity
• Buddy
• AppVeyor
  But Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

Takes a cookie string and removes certain name-value pairs.

When setting a cookie that contains "HttpOnly;" as in the example:

server.inject({
    method: 'GET',
    url: `/?${qs.stringify(qry)}`,
    headers: {
         'Cookie': 'cms-preview-token=<token>; HttpOnly; SameSite=Strict'
    }
})

returns:

{ statusCode: 400,
  error: 'Bad Request',
  message: 'Invalid cookie header' }

stripping HttpOnly; from the string fixes the issue.

Currently it is not possible to utilize Irons password rotation, since there is no way to provide the actual list of rotated passwords.

Would be willing to open a PR for it, but wanted to firstly ask if you would be willing to get this supported or if you do not want it to be supported.

In our project, Snyk reported [email protected] as a dependency with a known security vulnerability
The latest version of cryptiles (4.1.2) seems to have fixed this vulnerability.

More info about the (medium severity) vulnerability in [email protected] can be found at
https://snyk.io/vuln/npm:cryptiles:20180710

No clue where this came from. It was in the very first version in hapi 0.7.0.

Clean tests according to outmoded/discuss#24

Querystring is required here but it's not a dependency here

Backport #55

It's time.

I am using hapi to check for the existence of a Drupal session cookie (which uses standard PHP sessions).

Here's a cookie sample:

SSESS9cb1fc0ca1a49c727c541be17760f1e0=BqZEqcKD9uuQySX9rC_OvvQDngN0DMCuF5S44xgcYPE

a cookie like this is property formatted in the header (it can be read by PHP); however, statehood fails to parse it. :(

even when I set strictHeader to false the cookie does not come through.

Other cookies appear fine. I double checked the request headers with request.headers.cookie and the cookie is in the header, but it is not in request.state

hapijs/hapi#3516

I have a situation where there are multiple cookies with the same name (different paths) being sent in the request. If even just one of the cookies can't be decoded, the rest of the cookies (even if they can be decoded) are not returned.

Is this the desired behavior? If not, it seems like it could be fixed if nextName() was replaced with nextArray() here: https://github.com/hapijs/statehood/blob/master/lib/index.js#L228

Problem Statement:
Provide documentation for Statehood.

Description:
I am currently using Statehood library for cookie parsing and signing for few projects. So the library has been really useful and providing support for singing, encryption and encoding out of box.

Solution:
I would like to provide a documentation for this library. Will the PR be accepted for this?

This attribute has shipped with chrome 51, seems like a nice thing for statehood and hapi to support as well.

https://tools.ietf.org/html/draft-west-first-party-cookies-07#page-3

Set-Cookie: SID=31d4d96e407aad42; SameSite=Strict

Possible values are None, Strict, and Lax https://tools.ietf.org/html/draft-west-first-party-cookies-07#section-4.1.1

https://github.com/hapijs/statehood/blob/master/lib/index.js#L313-L318