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

Coerced types are thrown away #144

Open
henhal opened this issue Mar 10, 2021 · 7 comments
Open

Coerced types are thrown away #144

henhal opened this issue Mar 10, 2021 · 7 comments

Comments

@henhal
Copy link
Contributor

henhal commented Mar 10, 2021

When a request is handled, parseRequest() is called to parse the request using an operation. Then, the validator is called to validate the request. However, the parsed request is not passed to the validator; instead the validator parses the request again. It then validates the local parsed request using coerceTypes, which means AJV mutates that local parsed request only. This is then thrown away, meaning that the parsed request kept in the context and passed to the operation handlers does not have coerced types etc.

Example: An operation has a header with schema: {type: number}. On a raw request, of course all headers are strings. However, inside validateRequest(), the header is coerced so that foo: '42' becomes foo: 42, but this coercion happens on a local copy of the parsed request. The result is that once the parsed request reaches the operation handler, the headers are again all strings.

Shouldn't the validator take a parsed request instead of a raw request (which it currently internally parses one more time, then validates and potentially mutates it, before throwing it away), so that a parsed request could actually have coerced headers etc?

Edit: I just realized that ParsedRequest also actually only supports string params, so I guess this is somewhat deliberate? However, there are instances of ParsedRequest inside the validator which momentarily contain non-strings, since ajv coerces in-place, so that's not very robust. But again, that object is thrown away.
Expanding ParsedRequest into headers and other parameters of type string | number | boolean would be a breaking change, but it would allow parameters to be coerced properly. Let me know if PRs are welcome in this area, and if so whether you have any specific thoughts or constraints to keep in mind.

@mdebarros
Copy link

mdebarros commented Jun 4, 2021

+1 for this.

The "coersion" was working on 3.6.3, but no longer in 3.9.2.

I have also confirmed that this impacts all parameters, i.e. query, path, headers body, etc.

@anttiviljami
Copy link
Member

anttiviljami commented Jun 4, 2021 via email

@nklisch
Copy link

nklisch commented Jan 1, 2023

This seems to still be an open issue, as I am seeing this problem as well

@nklisch
Copy link

nklisch commented Jan 1, 2023

@anttiviljami The second PR on this issue seems rather stale, would you accept a new one to parse, and if the user choses, coerce the types via AJV coerceTypes option?

@nklisch
Copy link

nklisch commented Jan 1, 2023

Also, I'd like to update the Context object type so it can take in a type for the params, allowing typescript intellisense, like how Express requests work, since we are placing the parsed requests in that object.

@anttiviljami
Copy link
Member

@nklisch Another PR would be appreciated indeed. 🙏 I like both ideas. 👍

@sabeslamidze
Copy link

Could this be a fix #571? Will be glad to collaborate on this and get it merge asap. Thank you!

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

5 participants