couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: CORS feature.
Date Wed, 30 Nov 2011 10:36:31 GMT
On Mon, Nov 28, 2011 at 9:03 PM, Randall Leeds <randall.leeds@gmail.com> wrote:
> 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
>>

My bad, thought you just edited the link. ABout /_uuids & ... we
should probably describe it as well, shouldn't we?

- benoît

Mime
View raw message