Send cookies explicitly into context.request's transaction
#3322
Conversation
github-actions
bot
added
the
agent-nodejs
david-luna
changed the title
context.request's transaction
package-lock.json
Outdated
| @@ -21594,6 +21612,29 @@ | |||
| "integrity": "sha512-OPs5WnnT1xkCBiuQrZA4+YAV4HEJejmHneyraIaxsbev5yCEr6KMwINNFP9wQeFIw8FWcoTqF3vQsa5CDaI+8Q==", | |||
| "dev": true | |||
| }, | |||
| "@types/node-fetch": { | |||
There was a problem hiding this comment.
Doing a client checkout of main and npm i produces also this addition so I guess its dependency not locked in a previous PR.
There was a problem hiding this comment.
This should be from https://github.com/elastic/apm-agent-nodejs/pull/3318/files
lib/parsers.js
Outdated
| @@ -58,6 +60,15 @@ function getContextFromRequest (req, conf, type) { | |||
| Object.assign({}, req.headers), | |||
| conf.sanitizeFieldNamesRegExp | |||
| ) | |||
|
|
|||
| // TODO: deprecate filterHttpHeaders in next major release | |||
There was a problem hiding this comment.
We might be disagreeing on the definition of "deprecate". For me, "deprecating" means that we would document (and mark in types) that the config var is "deprecated" -- hence users should avoid it and the docs should show users how to migrate away from it, but the field is still supported.
The "TODO" for the next major release would be to remove the filterHttpHeaders config var.
Thoughts?
If we agree, then would you like to do the deprecation tweaks in this PR, or prefer that we do it in a separate change?
There was a problem hiding this comment.
I think your approach is much better. I shall do the changes in #3320 before next major
Thanks!
Co-authored-by: Trent Mick <trent.mick@elastic.co>
* feat: add cookies object into context.request --------- Co-authored-by: Trent Mick <trent.mick@elastic.co>
Description
This PR changes the transaction serialisation to be more explicit about sanitization of sensitive data in request's
cookieheader.Current status
cookies are sanitized in the header value based on sanitizeFieldNames configuration. As a result you see clear values and redacted ones. This may lead to think the agent is not properly doing sanitization.
After this PR
cookies are going to be placed in
context.request.cookiesmap, which is accepted by the intake API, and sanitized based on the configuration. The cookie header will be completely redacted to avoid duplication of data.Fixes: #3273
Checklist