CKAN: Ticket #318: Insufficient validation of resource URIs

wwaites — Thu, 20 May 2010 17:43:05 GMT

Some more datapoints from Leigh Dodds of Talis:

I'm still having no joy with this I'm afraid. I'm test parsing the data locally using the TDB command-line tools, specifically tdbcheck which will parse the data and generate warnings/exceptions. This uses the same parsing code, data and URI validation code as we're using on the Platform.

Currently its giving me warnings for invalid lexical values for dates, e.g:

Lexical not valid for datatype: "2008"http://www.w3.org/2001/XMLSchema#date

While these aren't a major issue, looking at some of the data suggests that there are more underlying data problems that need checking and fixing up, e.g:

Lexical not valid for datatype: "n/a"http://www.w3.org/2001/XMLSchema#date Lexical not valid for datatype: "27/04/2006 13:56"http://www.w3.org/2001/XMLSchema#date Lexical not valid for datatype: "Real time calculation"http://www.w3.org/2001/XMLSchema#date Lexical not valid for datatype: "varies by country"http://www.w3.org/2001/XMLSchema#date

And there are still some invalid URIs, e.g:

<https://mqi.ic.nhs.uk/IndicatorDataView.aspx?query=NRLS%3&ref=3.02.16> Code: 30/ILLEGAL_PERCENT_ENCODING in QUERY: The host component a percent occurred without two following hexadecimal digits.

Can I suggest you try running the converted data through tdbcheck to iron out any problems? Then I can push it into the Platform.

owner, priority, description changed; milestone set

rgrp — Fri, 28 May 2010 18:55:40 GMT

owner changed from rgrp to dread
priority changed from major to blocker
description modified (diff)
milestone set to v1.1

owner changed

dread — Mon, 31 May 2010 15:44:37 GMT

owner changed from dread to rgrp

We can't change any of the metadata without permission from the various departments who supplied it.

I think "Don't shoot the messenger" is apt here.

Adding this to the form validation isn't going to change any of the existing data. I think this is better off in the data quality scoring.

wwaites — Fri, 11 Jun 2010 15:49:03 GMT

url validation reputed to be here:

http://www.livinglogic.de/Python/url/Howto.html

wwaites — Sun, 13 Jun 2010 14:19:53 GMT

Some good news, ll.url seems to take bad urls and make them into good urls.

viz:

In [1]: from ll import url
In [2]: print url.URL("https://mqi.ic.nhs.uk/IndicatorDataView.aspx?query=NRLS%3&ref=3.02.16")
------> print(url.URL("https://mqi.ic.nhs.uk/IndicatorDataView.aspx?query=NRLS%3&ref=3.02.16"))
/Users/ww/Work/OKF/ckanrdf/lib/python2.6/site-packages/ll/url.py:2358: UserWarning: truncated escape at position 4
  value = _unescape(namevalue[1].replace("+", " "))
https://mqi.ic.nhs.uk/IndicatorDataView.aspx?query=NRLS%253&ref=3%2E02%2E16

wwaites — Sun, 13 Jun 2010 14:20:32 GMT

Also fyi, getting ll.url is done like so

{{ pip install ll-xist }}}

wwaites — Sun, 13 Jun 2010 14:21:47 GMT

I've updated ckanrdf to strip out datatypes and use this ll.url on external references so that should be sufficient to hold off talis.

Still need to work particularly on validating dates though...

owner changed

rgrp — Mon, 14 Jun 2010 13:11:45 GMT

owner changed from rgrp to dread

owner changed; milestone deleted

rgrp — Mon, 02 Aug 2010 08:24:47 GMT

owner changed from dread to rgrp
milestone v1.1 deleted

owner changed

rgrp — Mon, 02 Aug 2010 08:27:00 GMT

owner changed from rgrp to pudo

Important but low priority according to CO so bumping into next milestone (v1.2). NB: did not seem able to update milestone in trac interface! (Perhaps due to agilo stuff?)

wwaites — Mon, 30 Aug 2010 14:49:28 GMT

CO may not realise the implications when they said it was low priority. The implication of this lack of validation is that it is impossible to generate valid URIs in the RDF which means it cannot be imported by Talis. So until there is a solution to this, no RDF catalog.

priority changed

rgrp — Sat, 29 Jan 2011 22:39:28 GMT

priority changed from blocker to awaiting triage

Still not sure what the priority is so moving to awaiting triage.

status changed; resolution set

pudo — Mon, 31 Jan 2011 09:48:28 GMT

status changed from new to closed
resolution set to wontfix

This will be implicit in #852, thus not building something specific for it now.

priority, status changed; resolution deleted

wwaites — Mon, 31 Jan 2011 13:54:09 GMT

priority changed from awaiting triage to major
status changed from closed to reopened
resolution wontfix deleted

We still require form validation to check URIs. They are not free-form strings. This is not the same as 852 or necessarily included in it.

owner, status changed; repo, theme, milestone set

thejimmyg — Wed, 20 Jul 2011 15:41:37 GMT

owner changed from pudo to johnglover
repo set to ckan
theme set to none
status changed from reopened to assigned
milestone set to ckan-current-sprint

Assigning to John so that he can see whether the QA code correctly flags these kinds of problems. If it does, we can close this ticket because although the API will serve invalid URLs, the publishers will be notified to clean up.

status changed; resolution set

johnglover — Wed, 27 Jul 2011 12:44:43 GMT

status changed from assigned to closed
resolution set to fixed

The QA code should identify invalid URLs. Resources with invalid urls will have an 'openness_score' of 0 and an 'openness_score_reason' of 'Invalid url scheme' or 'invalid URL'.

dread — Tue, 09 Oct 2012 10:31:02 GMT

Here's a real example - one of many from MOD http://www.dasa.mod.uk/applications/newWeb/www/index.php?page=48&thiscontent=180&date=2011-05-26&pubType=1&PublishTime=09:30:00&from=home&tabOption=1 Browsers accept colons and slashes happily, which is the main usage of our links. The URL looks better with the colons and slashes, rather than the encoded version. The average departmental user doesn't understand that the reason to encode them is for some academic RFC and RDF which is not "liberal in what it accepts". Since the RDF tool has a satisfactory way to encode links, this problem is essentially solved. Therefore I'm changing ckanext-archiver to accept these unencoded links, I'm afraid.