Open ThrawnCA opened 4 years ago
Relying on a cookie to authenticate the API intended to be used from a user's browser on the resource page is completely normal. Maybe I'm misunderstanding your issue.
It's normal, yes, but it's actually a really bad idea. Unlike a regular HTTP form, it's quite difficult for an API endpoint to detect and block cross-site request forgery. Which means that if you're logged in, then any site you visit can send API requests that will have your authentication stamped on them.
There are extensions that add a filter to block this (like https://github.com/data-govt-nz/ckanext-security) but they don't work properly on API endpoints. Dropping cookies on API endpoints is effective, but only feasible when API keys, not cookies, are used for authentication.
There is more information at https://lists-archive.okfn.org/pipermail/security/2014-November/000281.html about the problems with allowing cookie based authentication to APIs.
The AJAX-based multipart upload assembles an API call that relies on cookies to authenticate, instead of obtaining the user's API key.
From a security standpoint, allowing cookie-based authentication to an API that cannot properly check for Cross-Site Request Forgery is a very bad idea. We deal with this on our site by stripping cookies for API calls. However, that filter breaks this extension.