Changes to API authentication: support both new API Token and legacy API key

[florianm]

CKAN is slowly moving away from the legacy API key as means of authentication and moving towards an API token. The official docs on this are at http://docs.ckan.org/en/latest/api/index.html#authentication-and-api-tokens.

Spec change

Starting from CKAN 2.9 the recommended mechanism to use are API tokens. These are encrypted keys that can be generated manually from the UI (User Profile > Manage > API tokens) or via the api_token_create() function. A user can create as many tokens as needed for different uses, and revoke one or multiple tokens at any time. In addition, enabling the expire_api_token core plugin allows to define the expiration timestamp for a token.

Legacy API keys (UUIDs that look like ec5c0860-9e48-41f3-8850-4a7128b18df8) are still supported, but its use is discouraged as they are not as secure as tokens and are limited to one per user. Support for legacy API keys will be removed in future CKAN versions.

The breaking change will likely affect CKAN installations not before v2.10.

ckanr changes

• A test server running CKAN 2.9+ to offer API Token auth
• ckanr_settings(): existing API Key is called key, so maybe add token to getters, setters, env var CKAN_API_TOKEN.
• ckanr_VERB should use api_token (if available) over api_key (if available) over unauthenticated request (fallback).
• Vignette "Get started": update
• NEWS communicate change to ckanr users
• Message on package startup re change (if not too annoying), similar to drake/targets deprecation warnings

[hannaboe]

Are API tokens implemented in ckanr?

[fjuniorr]

@hannaboe from a ckanr standpoint you can just pass the API token everywhere the API key is expected.