feat(serializers): avoid implicit sanitization #2081
Conversation
lib/proto.js
Outdated
| } else if (_obj instanceof IncomingMessage) { | ||
| obj = { [requestKey]: _obj } | ||
| } else if (_obj instanceof ServerResponse) { | ||
| obj = { [responseKey]: _obj } |
There was a problem hiding this comment.
If preferred, we can assess type from properties, as previously done in lib/tools.js:
} else if (_obj.method && _obj.headers && _obj.socket) {
obj = { [requestKey]: _obj }
} else if (typeof _obj.setHeader === 'function') {
obj = { [responseKey]: _obj }
There was a problem hiding this comment.
I think property presence will be better here. These could be extended objects, e.g. a FastifyRequest.
| } else if (key === requestKey && serializers.req) { | ||
| value = serializers.req(value) | ||
| } else if (key === responseKey && serializers.res) { | ||
| value = serializers.res(value) |
There was a problem hiding this comment.
Behaviour of all stdSerializers follow the same pattern.
| /** | ||
| * The string key for the 'Request' in the JSON object. Default: "req". | ||
| */ | ||
| requestKey?: string; | ||
| /** | ||
| * The string key for the 'Response' in the JSON object. Default: "res". | ||
| */ | ||
| responseKey?: string; |
There was a problem hiding this comment.
The key for request and response are now explicitly configurable. Previously, these had fixed values, set on pino-std-serializers (mapHttpRequest and mapHttpResponse).
There was a problem hiding this comment.
maybe this change makes the exported functions mapHttpRequest and mapHttpResponse deprecated, in pino-std-serializers?
When serializers are defined for HTTP Request or HTTP Response, do not run the correspondent `stdSerializers` before calling the provided serializer functions. ISSUE pinojs#1991
gerardolima
force-pushed
the
override-http-std-serializers
branch
from
f705b9c
to
a3b1681
Compare
test/http.test.js
Outdated
| @@ -160,34 +154,31 @@ test('http response support', async ({ ok, same, error, teardown }) => { | |||
| server.close() | |||
| }) | |||
|
|
|||
| test('http response support via a serializer', async ({ ok, same, error, teardown }) => { | |||
| test('http response support via a serializer', async ({ match, error }) => { | |||
There was a problem hiding this comment.
can you please keep the previous test and only add a new one?
There was a problem hiding this comment.
Original tests restored. Also fixed linter issues.
|
ok, I was running isolated tests and only now I noticed there were some assertions on the default serialisers; I am fixing them right now and soon the tests will be fixed; sorry for the silly mistake |
|
hey, @mcollina, are these the changes you expected? is there something that needs improvement or still missing? |
lib/proto.js
Outdated
| } else if (_obj instanceof IncomingMessage) { | ||
| obj = { [requestKey]: _obj } | ||
| } else if (_obj instanceof ServerResponse) { | ||
| obj = { [responseKey]: _obj } |
There was a problem hiding this comment.
I think property presence will be better here. These could be extended objects, e.g. a FastifyRequest.
This changeset only modifies the following behviour: neither logged Request nor Response objects are not transformed by their corresponding This change in behaviour is asserted in test/http.test.js, lines 86 and 240, with tests that create an arbitrary property that should be removed from them, if their standard serializers ran. |
This is a breaking change, correct? |
Yes, this is correct. When custom serializers are provided and they depend on the changes made by the standard serializers on the target objects (ie: to sanitize them?), they will be impacted. Though running standard serializers when custom serializers are given is not exaclty obvious behaviour -- and I think nor documented --, I understand there might be code in the wild that dependes on it (Hyrum's Law) and publishing this as breaking change should be the safest strategy. |
Then we are missing the deprecation and opt-in for the current version. |
When serializers are defined for HTTP Request or HTTP Response, do not run the correspondent
stdSerializersbefore calling the provided serializer functions.ISSUE #1991