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

Breaking change with query string validation from 8.6.0 to 9.0.2 #2718

Closed
dynajoe opened this issue Aug 16, 2015 · 9 comments
Closed

Breaking change with query string validation from 8.6.0 to 9.0.2 #2718

dynajoe opened this issue Aug 16, 2015 · 9 comments
Assignees
Milestone

Comments

@dynajoe
Copy link

@dynajoe dynajoe commented Aug 16, 2015

I'm receiving a validation failure for requests that worked before upgrading from 8.6.0 to 9.0.2.

The validation that previously worked for query strings of the form ?sensor.battery.eq=4.02:

query: Joi.object({
   type: Joi.string()
}).pattern(/sensor\.[a-z0-9_]+\.(gte|gt|lte|lt|ne|eq)/i, Joi.number())

This is no longer valid after the upgrade. I get the error:

{"statusCode":400,"error":"Bad Request","message":"\\"sensor\\" is not allowed","validation":{"source":"query","keys":["sensor"]}}

in 8.6.0 -- request.query was:

{ 'sensor.battery.eq': 4.02 }

In 9.0.2 -- request.query now looks like:

// request.query
{ sensor: { battery: { eq: '4.02' } } }
@dynajoe
Copy link
Author

@dynajoe dynajoe commented Aug 16, 2015

This seems to be the reason for the breakage:

ljharb/qs@6ee5df7

@hueniverse
Copy link
Contributor

@hueniverse hueniverse commented Aug 16, 2015

This comes from an improperly documented change in qs.

@nlf can you help figure out what's the best way to handle this?

@bear
Copy link

@bear bear commented Aug 18, 2015

@nlf may be slow in responding to this thread as he is currently back woods camping

@dynajoe
Copy link
Author

@dynajoe dynajoe commented Aug 19, 2015

There is an option in qs to disable this behavior. Perhaps hapi could expose this or disable it?

@hueniverse
Copy link
Contributor

@hueniverse hueniverse commented Aug 19, 2015

You can already pass options to qs for both payload and query string processing.

@nlf
Copy link
Member

@nlf nlf commented Aug 24, 2015

Yeah, dots should've been disabled by default, this one is my fault. For right now you can pass allowDots: false in your options for qs and it will resolve your issue.

@hueniverse hueniverse added this to the 9.0.0 milestone Aug 25, 2015
@hueniverse hueniverse removed the bug label Aug 25, 2015
@hueniverse hueniverse self-assigned this Aug 25, 2015
@hueniverse
Copy link
Contributor

@hueniverse hueniverse commented Aug 25, 2015

We're stuck with this now. I've updated the release notes to reflect this change.

@hueniverse hueniverse closed this Aug 25, 2015
@dynajoe
Copy link
Author

@dynajoe dynajoe commented Jul 11, 2016

How is this being exposed in 13.5.0?

@dynajoe
Copy link
Author

@dynajoe dynajoe commented Jul 11, 2016

I found the information I needed from the migration docs:

const Url = require('url');
const Qs = require('qs');

const onRequest = function (request, reply) {

    const uri = request.raw.req.url;
    const parsed = Url.parse(uri, false);
    parsed.query = Qs.parse(parsed.query);
    request.setUrl(parsed);

    return reply.continue();
};

server.ext('onRequest', onRequest);

@lock lock bot locked as resolved and limited conversation to collaborators Jan 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants