[ckan-dev] API Validation

[Toby Dacre]

I can look. I thought it'd be picked up in validate() rather than in the
dictization. It would be nice to pick up all the errors not just the first
to be hit.  See what makes the most sense.

On 9 March 2012 18:10, David Read <david.read at hackneyworkshop.com> wrote:

> PS I was thinking about raising an error in dictization like this (see
> below) but there are no Exception objects defined or other raises in
> lib/dictization and assumed this would be picked up in validation.
>
> Dave
>
> diff --git a/ckan/lib/dictization/model_save.py
> b/ckan/lib/dictization/model_save.py
> index 1f12b09..46fdb3b 100644
> --- a/ckan/lib/dictization/model_save.py
> +++ b/ckan/lib/dictization/model_save.py
> @@ -423,6 +423,9 @@ def package_api_to_dict(api1_dict, context):
>             else:
>                 new_value = [{"name": item} for item in value]
>         if key == 'extras':
> +            if not isinstance(extras, dict):
> +                raise ParameterError('Value for key "%s" must be of
> type "%s"' %
> +                                     key, 'dict')
>             updated_extras = {}
>             if package:
>                 updated_extras.update(package.extras)
>
> On 9 March 2012 18:06, David Read <david.read at hackneyworkshop.com> wrote:
> > Toby,
> >
> > Great to hear about this being in place now! I've been using a branch.
> > I'll try it out.
> >
> > Here's a test showing the sort of bad input that still slips through.
> > I'd like to see it come up with a validation error, ideally saying
> > which field is the problem:
> >
> > https://gist.github.com/2007796
> >
> > What do you think?
> >
> > Dave
> >
> > On 9 March 2012 17:57, Toby Dacre <toby.okfn at gmail.com> wrote:
> >> David,
> >>
> >> The api validation should be using the schema specified in the
> DatasetForm
> >> using the form_to_db_schema_options(options) function where options is a
> >> dict with keys of 'api' (bool) and 'type' (str) of 'create' or
> 'update'.  If
> >> this function is not defined we fall back to form_to_db_schema().
> Similar
> >> logic is used for GroupForms. See lib.plugins for the default
> >> implementations.  I'd prefer the api/forms to share an identical schema
> but
> >> currently this isn't the case.
> >>
> >> I'm not sure what the error handling issues are I can look at the 500
> issue
> >> and see if we can give better feedback.  Question: how should we return
> >> errors from the api are these textual or as a json dict of field error
> >> types?
> >>
> >> I'm pretty sure this change has got into the next release.
> >>
> >> Toby
> >>
> >> On 9 March 2012 16:28, David Read <david.read at hackneyworkshop.com>
> wrote:
> >>>
> >>> My clients are using the CKAN API and are suffering a little due to
> >>> the inputs not being validated.
> >>>
> >>> For example, when they ask CKAN to create a dataset, and the JSON they
> >>> include mistakenly has a list instead of dict, they get simply '500
> >>> Server Error' - not very helpful.
> >>>
> >>> The CKAN forms use the excellent validation system, so we are adding
> >>> validators for some of our custom fields. But of course we'd like this
> >>> validation to also apply to metadata coming in via the API too.
> >>>
> >>> I understand you've been talking about making calls to it in the
> >>> RESTful APIs - is that in the works now? Is it headed for the
> >>> forthcoming 1.6.1 release?
> >>>
> >>> Dave
> >>>
> >>> _______________________________________________
> >>> ckan-dev mailing list
> >>> ckan-dev at lists.okfn.org
> >>> http://lists.okfn.org/mailman/listinfo/ckan-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> ckan-dev mailing list
> >> ckan-dev at lists.okfn.org
> >> http://lists.okfn.org/mailman/listinfo/ckan-dev
> >>
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20120309/30404267/attachment-0001.html>