couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: CORS feature.
Date Mon, 28 Nov 2011 20:03:37 GMT
On Mon, Nov 28, 2011 at 02:50, Benoit Chesneau <bchesneau@gmail.com> wrote:
> On Mon, Nov 28, 2011 at 11:38 AM, Benoit Chesneau <bchesneau@gmail.com> wrote:
>> Hi,
>> We had a great discussion today Jason, Randall and me about the CORS
>> feature [1] .
>> I'm positing here the current result that you can find on friendpaste
>> [2] too. I think it's
>> a pretty good start and we can begin to code it. Implementation is
>> mostly a merge
>> between jason proposal and mine imo. Thoughts ?
>>
>> - benoît
>>
>> [1] https://issues.apache.org/jira/browse/COUCHDB-431
>> [2] http://friendpaste.com/4q1zeNUEtPFS7XbioPYYzM
>>
>> guidelinees :
>> ------------------
>>
>>    - rules shoudl be based on host .
>>    - rules depending on the resource :
>>      - server : rules defined in .ini
>>      - db : rules defined in .db
>>
>>    - default cors policy :
>>        - allows credential = false
>>        - cors enabled
>>    - cors can be disabled globaly
>>
>>
>>
>>    rules definiton :
>>
>>    global wide
>>
>>    [httpd]
>>    cors_enabled = true
>>
>>    [origins]
>>    domain.tld = http://origin.tld, https://origin.tld
>>
>>    [http://origin.tld]
>>    allow_methods = GET, POST
>>    allow_headers = x-couchdb-...
>>    allow_credentials = false
>>
>>
>>    [https://origin.tld]
>>    allow_methods = GET, PUT, POST, DELETE
>>    allow_headers = x-couchdb-...
>>    allow_credentials = true
>>    allow_server_admins = true
>>    max-age = 36000
>>
>>
>>    ond db _security object :
>>
>>
>>    {
>>        "origins": {
>>            "domain.tld": [
>>                {"http://origin.tld": { "allow_methods": "GET, POST",
>>    ...}
>>            ]
>>        }
>>    }
>>
>>
>>
>>    work flow :
>>
>>    is origins list empty in ini
>>    yes -> is admin party set ?
>>      yes -> return "*" , credentials false (with a good caching policy)
>>      no -> stop
>>    no ->
>>      is origin in .ini ?
>>      yes ->
>>        is origin in list ?
>>        yes ->
>>          set the cors headers based on .ini
>>          then are we on a db resource ?
>>            yes ->
>>              apply the intersection of .ini with db resource
>>        no -> stop
>>      no ->
>>

This last bit is wrong, IMO. The paste has an updated version.
I also simplified it just now to distinguish between /db(/...)
resources and "special" paths (/_uuids, etc).
My current suggestion is to use the db _security object when
available, and fall back to .ini config.
This allows admins to configure .ini and never have to touch dbs, but
db administrators can configure their own CORS.
Of course, server admins can still disable cors globally.
I feel like this hits all the use cases. Also the flow in the paste
now explains neatly how a chain of rewrites from dbs A->B->C would
have to check CORS permissions for each db it touches.

http://friendpaste.com/4q1zeNUEtPFS7XbioPYYzM

>
>
> quick not about hosts. It should be abble to set '*' to manage origins
> for any hosts.
>
> - benoît
>

Mime
View raw message