Open KrisSiegel opened 9 years ago
Great question. This issue may give you some context.
At the time I built this module, they didn't allow other implementations to be used within the validate config.
With that said, I actually wouldn't mind changing the module to use the built in validate config, but I just haven't had time to update it.
Understood. Thanks!
With this ticket closed does that mean you won't end up moving to the built in config? Or will that go into a new ticket?
I was going to create a new one, but I'll actually just leave this one open for some additional context
Hi,
I tried to write a plugin which would check if object given to config.validate
is a JSON schema and act according to, but I failed. How is it possible even in latest version of Hapi? (v11.1.2 as of this message is written)
From hapi.js /lib/route.js line: 260
internals.compileRule = function (rule) {
// null, undefined, true - anything allowed
// false - nothing allowed
// {...} - ... allowed
return (rule === false ? Joi.object({}).allow(null)
: typeof rule === 'function' ? rule
: !rule || rule === true ? null // false tested earlier
: Joi.compile(rule));
};
If you provide JSON schema as an object to standard config.validate.payload
etc. of a route, hapi directly tries to convert it to JOI object. This is also clearly stated in API docs of hapi. As a result you cannot access bare JSON schema even in onPostAuth
, since it is already converted as below:
{ options: {},
params:
{ isJoi: true,
_type: 'object',
_settings: null,
_valids: { _set: [] },
_invalids: { _set: [] },
_tests: [],
_refs: [],
_flags: {},
_description: null,
_unit: null,
_notes: [],
_tags: [],
_examples: [],
_meta: [],
_inner:
{ children: [Object],
renames: [],
dependencies: [],
patterns: [] } },
payload: null,
headers: null,
query: null }
I will also open a ticket about this in hapi repository, but I will appreciate if you suggest any ideas how to achieve this in current version?
For update. I asked in hapi repository and got an answer. It seems impossible according to hapijs/hapi#2967.
I've been exploring a few different options for automatic schema validation and API documentation. I noticed both lout and hapi-swagger support the following configuration for routes:
But ratify seems to require a different type of configuration structure with everything under a plugins and then a ratify object.
Is there a reason for the different structure? Would it be possible to re-use the same structure that others use that don't specify the ratify plugin explicitly? I mostly just want an easy way to keep things consistent but have the option of changing out documentation and / or validations.