[ckan-dev] API Validation

[David Read]

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
>>