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

validation fails when using Hapi.types.Object() at the root #1004

Closed
pgte opened this issue Aug 2, 2013 · 3 comments
Closed

validation fails when using Hapi.types.Object() at the root #1004

pgte opened this issue Aug 2, 2013 · 3 comments
Assignees
Labels
bug Bug or defect
Milestone

Comments

@pgte
Copy link

pgte commented Aug 2, 2013

When using Hapi.types.Object() at the root of a validation specification, a request fails with the following trace:

TypeError: Object function (value, obj, key, errors, keyPath) {

        if (typeof value !== 'object') {
            errors.add('the value of ' + key + ' must be an object', keyPath);
            return false;
        }

        return self._traverse(value, self._config, errors, keyPath);
    } has no method 'validate'
    at validateKeyConfig (/Users/pedroteixeira/projects/test/node_modules/hapi/node_modules/joi/lib/index.js:77:47)
    at processConfig (/Users/pedroteixeira/projects/test/node_modules/hapi/node_modules/joi/lib/index.js:56:13)
    at Object.exports.validate (/Users/pedroteixeira/projects/test/node_modules/hapi/node_modules/joi/lib/index.js:111:5)
    at exports.payload (/Users/pedroteixeira/projects/test/node_modules/hapi/lib/validation.js:25:21)
    at /Users/pedroteixeira/projects/test/node_modules/hapi/lib/request.js:300:13
    at iterate (/Users/pedroteixeira/projects/test/node_modules/hapi/node_modules/async/lib/async.js:131:13)
    at /Users/pedroteixeira/projects/test/node_modules/hapi/node_modules/async/lib/async.js:142:25
    at /Users/pedroteixeira/projects/test/node_modules/hapi/node_modules/hoek/lib/index.js:582:22
    at process._tickDomainCallback (node.js:459:13)

Simple test case:

var Hapi        = require('hapi');
var server = Hapi.createServer('0.0.0.0', 8080);

var types = Hapi.types;

var query = types.Object({
    param: types.String().required()
  }, true);

query.___test = true;

var validate = {
  query: query
};

server.route({
  method: 'GET',
  path: '/test',
  config: {
    validate: validate,
    handler: handler
  }
});

server.start();

function handler(req) {
  req.reply('HAY');
}

Start the server and then query it:

$ curl http://localhost:8080/test?param=true

I have pinned it down to the fact that hapi clones the route config, loosing the joi.types.Object type at the root.

@ghost ghost assigned geek Aug 2, 2013
@geek
Copy link
Member

geek commented Aug 2, 2013

I can confirm this and am working on a fix. I believe it will be a fix in the hoek module.

@papajuans
Copy link

Can someone explain the second argument (true) to types.Object and also query.__test = true?

I was able to get this working by just unwrapping query from types.Object:

var Hapi = require('hapi');
var server = Hapi.createServer('0.0.0.0', 8080);

var types = Hapi.types;

var query = { 
  param: types.String().required()
};

var validate = {
  query: query
};

server.route({
  method: 'GET',
  path: '/test',
  config: {
    validate: validate,
    handler: handler
  }
});

server.start();

function handler(req) {
  req.reply('HAY');
}

As an aside, I ran into very similar, if not the same issue, when trying to set validate.payload to a Joi schema defined in a separate node module. I ended up unwrapping schemas from types.Object(), similar to above, and also having to run npm dedup in order to enforce the same Joi instance being returned when required().

@geek
Copy link
Member

geek commented Sep 12, 2013

Thanks for the feedback, I am not seeing anything related to a second parameter for Object. The only parameter used is the configuration object.

@ghost ghost assigned hueniverse Oct 1, 2013
jmonster pushed a commit to jmonster/hapi that referenced this issue Feb 10, 2014
@lock lock bot locked as resolved and limited conversation to collaborators Jan 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Bug or defect
Projects
None yet
Development

No branches or pull requests

4 participants