CKAN: Ticket #1001: API should use normal user credentials if available

milestone changed

rgrp — Mon, 28 Feb 2011 10:35:05 GMT

milestone changed from ckan-v1.4-sprint-2 to ckan-v1.4-sprint-3

description changed; repo, theme set

rgrp — Thu, 17 Mar 2011 10:58:29 GMT

repo set to ckan
theme set to none
description modified (diff)

thejimmyg — Thu, 17 Mar 2011 13:12:35 GMT

Yes, I think the two should be consolidated, but as was noted elsewhere (I think) we don't want the API to ever be authenticated via a cookie, otherwise we open ourselves to CSRF attacks. Instead we could support the API key as a query parameter as an alternative to via the HTTP header if it is hard to set an HTTP header in JS libraries?

pudo — Sun, 20 Mar 2011 12:58:08 GMT

My vote on this would be to enable "httpbasic" auth via repoze.who and to add an API key challenger to ckan/lib/authenticator.py that accepts API keys, from within repoze.who. This way we won't have to work around the framework at all and can retain compatibility to the existing mechanisms.

milestone changed

rgrp — Mon, 21 Mar 2011 10:36:19 GMT

milestone changed from ckan-v1.4-sprint-3 to ckan-v1.4-sprint-4

First work in cset:6b8cbe465b61

pudo — Mon, 21 Mar 2011 10:44:09 GMT

Wrote a WDMMG version of this yesterday: https://bitbucket.org/okfn/wdmmg/changeset/398ce0eb3901#chg-wdmmg/lib/authenticator.py

status changed; resolution set

rgrp — Sun, 27 Mar 2011 12:31:22 GMT

status changed from new to closed
resolution set to fixed

Completed and merged into default in cset:cb200f339dbb. At the moment have done the very simple option but pudo's approach seems better and we could refactor towards that going forward.

status changed; resolution deleted

dread — Mon, 28 Mar 2011 10:23:34 GMT

status changed from closed to reopened
resolution fixed deleted

You mentioned writing tests? Also the CSRF question from James hasn't been addressed.

status changed; resolution set

rgrp — Mon, 28 Mar 2011 11:05:51 GMT

status changed from reopened to closed
resolution set to fixed

This ticket did not include CSRF matters - please raise in a separate ticket if you wish. I looked in some detail at the testing options and nothing seemed simple to do that didn't duplicate code we already have (since no way to access the base controller halfway through a request). This can be tested as necessary as part of the development of the new js work.