[access-control] non-GET authorization

Starting a new thread in order to summarize and narrow the topic a little.

So from what I understand there are at this point several proposals for 
how to authorize non-GET requests:

1) Perform a GET request to the same URI, use Content-Access headers in 
combination and A with Allow header to authorize the non-GET request.

   Pros:
     * GET requests are common, understood and supported both server and
       client side everywhere.
   Cons:
     * The GET request should be removed from caches by the following
       non-GET request, thus requiring a special header in order to avoid
       reauthorizing for every request.
     * Non standard way of checking for allowed methods over HTTP

2) Perform a OPTIONS request to the same URI, use Content-Access headers
in combination with Allow header to authorize the non-GET request.

    Pros:
      * Standard way of checking for allowed methods over HTTP.
    Cons:
      * OPTIONS requests aren't allowed to be cached, thus requiring a
        special header in order to avoid reauthorizing for every request.
      * OPTIONS in combination with Allow currently has a different
        meaning, not related to cross-site authorization, but rather
        general server features.
      * Apache sends by default an Allow header authorizing POST requests
        to CGIs which is believed to be unsafe in general. This might be
        mitigated enough by the fact that we also require Access-Control
        headers to be present.
      * Returning content from OPTIONS requests seems non-trivial with
        apache.

3) Perform a OPTIONS request to the same URI, use Content-Access headers
in combination with a new Method-Allow header to authorize the non-GET 
request.

    Cons:
      * OPTIONS requests aren't allowed to be cached, thus requiring a
        special header in order to avoid reauthorizing for every request.
      * Non standard way of checking for allowed methods over HTTP

4) Perform a GET request to a 'magic' different URI, use the contents of 
the returned file to somehow describe which URIs are accessible in what 
ways.

    Pros:
      * GET requests are common, understood and supported both server and
        client side everywhere.
      * The contents of the GET request will be cached in the UAs normal
        network cache, thus not requiring a need for separate caching.
    Cons:
      * We need a more complex format of describing access as the
        resource at the magic URI need to describe access to multiple
        URIs.
      * If we want to support micro-sites, the magic URI needs to reside
        in the same directory as the original resource, thus polluting
        more of the URI space.
        If we don't support micro-sites, non-GET requests will require
        server-wide cooperation.

5) Perform a OPTIONS request to a 'magic' different URI, use the 
returned file-content and/or headers to somehow describe which URIs are 
accessible in what ways.

    Cons:
      * OPTIONS requests aren't allowed to be cached, thus requiring a
        special header in order to avoid reauthorizing for every request.
      * OPTIONS requests specifying a URI is supposed to describe
        interaction with the specified URI, making this a non-standard
        use of OPTIONS.
      * We need a more complex format of describing access as the
        resource at the magic URI need to describe access to multiple
        URIs.
      * If we want to support micro-sites, the magic URI needs to reside
        in the same directory as the original resource, thus polluting
        more of the URI space.
        If we don't support micro-sites, non-GET requests will require
        server-wide cooperation.
      * Returning file-content from OPTIONS seems non-trivial in apache.
        If we rely on headers we'll end up with an even more complicated
        format due to having to describe ACL for multiple URIs in just
        headers.

Has there been any other suggestions? Have I missed any Pros/Cons? Feel 
free to add to the above list.

Personally I think 1 or possibly 2 looks best.

Regarding 2; OPTIONS feels somewhat more going with the spirit of HTTP, 
but beyond that I'm not sure what it buys us? And I dislike following 
standards for the sake of following standards. Standards aren't a goal 
in and of itself but rather there to make things work better.

I'm also not fully convinced that OPTIONS really is that much more in 
the spirit of HTTP as that's designed for checking for server 
capabilities, not for checking authorization which is really what we're 
doing here.

3 doesn't seem like a win over 1 in any way as it's just as it's as 
non-standard as anything else.

4 vs 1 is "cost of magic URIs" vs "cost of specialized caching". 
Personally I think the complexity of describing access control for 
multiple URIs will be as high as the complexity of a cache.

5 feels really messy as the we'll both have to have a specialized cache, 
deal with the complexity of describing multiple URIs, possibly squeezed 
into a single header, and deal with cost of magic URIs.

/ Jonas

Received on Thursday, 18 October 2007 23:46:34 UTC