[annotator-dev] HTTP headers required for annotator-store

Randall Leeds tilgovi at hypothes.is
Sat Aug 25 07:40:47 UTC 2012

On Sat, Aug 25, 2012 at 12:39 AM, Randall Leeds <tilgovi at hypothes.is> wrote:
> On Thu, Aug 16, 2012 at 2:14 PM, Kartik Subbarao <subbarao at computer.org> wrote:
>> I wanted to follow up on my posts from last week on the fluidinfo backend
>> store. I'm assuming that folks are pretty busy, but just wanted to ask if
>> anyone has had a chance to look at it yet. I'd like to at least get a basic
>> read if this is something that might be useful for the annotator project in
>> some form, or if it turns out not to be that useful after all.
> Very cool! That FluidInfo perl library looks very smooth.
> I wonder if there's more that can be done to decompose the data to add
> more information to the FI namespace. I'll have to look harder at FI.
>> Also, I wanted to ask whether the HTTP headers required for annotator-store
>> backends was documented somewhere. After some trial and error and looking at
>> the annotator-store code, I saw that I needed to add some CORS headers to
>> get it to work, like Access-Control-Allow-Origin and
>> Access-Control-Expose-Headers.
>> Also, the HTTP response to the OPTIONS command doesn't seem to be documented
>> on the storage API page:
>> https://github.com/okfn/annotator/wiki/Storage
> That's because these headers are dictating by the Cross Origin
> Resource Sharing spec [0].
> Currently, the necessary headers to expose (via
> Access-Control-Expose-Headers) are the default headers for most
> requests. For token requests, Access-Control-Allow-Credentials should
> be true if the token issuer requires cookie authentication. Finally,
> the X-Annotator-Auth-Token header carries the actual token value to
> the server.
> This could be better documented.
> Meanwhile, I've been scheming a bit more about auth in general. I'm
> thinking that the token situation is more similar to OAuth than I met
> have thought a few months ago. The need for
> Access-Control-Allow-Credentials bothers me because I'd rather not
> reason about whether a server might accidentally respond to malicious
> requests by a third party script and compromise its users. One of the
> objectives of issuing access tokens in a system like OAuth is to
> prevent the need to share login credentials with third parties. Even
> if the cookie is not the raw login details, it exposes the possibility
> of session hijacking. I have work I've discussed [1] to make it
> unnecessary to use CORS for Annotator, but I haven't yet sorted out
> how to manage the current UI in such a proposal.
> -Randall

Forgot references.

  [0] http://www.w3.org/TR/cors/

  [1] https://github.com/okfn/annotator/issues/119#issuecomment-6818502

More information about the annotator-dev mailing list