You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Benoit Chesneau <bc...@gmail.com> on 2011/11/28 11:38:20 UTC
CORS feature.
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 ->
Re: CORS feature.
Posted by Benoit Chesneau <bc...@gmail.com>.
On Mon, Nov 28, 2011 at 9:03 PM, Randall Leeds <ra...@gmail.com> wrote:
> On Mon, Nov 28, 2011 at 02:50, Benoit Chesneau <bc...@gmail.com> wrote:
>> On Mon, Nov 28, 2011 at 11:38 AM, Benoit Chesneau <bc...@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
Re: CORS feature.
Posted by Randall Leeds <ra...@gmail.com>.
On Mon, Nov 28, 2011 at 02:50, Benoit Chesneau <bc...@gmail.com> wrote:
> On Mon, Nov 28, 2011 at 11:38 AM, Benoit Chesneau <bc...@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
>
Re: CORS feature.
Posted by Benoit Chesneau <bc...@gmail.com>.
On Mon, Nov 28, 2011 at 11:38 AM, Benoit Chesneau <bc...@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 ->
>
quick not about hosts. It should be abble to set '*' to manage origins
for any hosts.
- benoît