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

Sat Aug 25 07:39:36 UTC 2012

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

>
> Here too, I used the annotator-store code as a reference and just copied
> what it was doing.

That works :). Thanks for doing this. You should add it to the storage
implementations section on https://github.com/okfn/annotator/wiki.