Re: CORS feature.
On Mon, Nov 28, 2011 at 9:03 PM, Randall Leeds randall.le...@gmail.com wrote:
On Mon, Nov 28, 2011 at 02:50, Benoit Chesneau bchesn...@gmail.com wrote:
On Mon, Nov 28, 2011 at 11:38 AM, Benoit Chesneau bchesn...@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
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.
On Mon, Nov 28, 2011 at 11:38 AM, Benoit Chesneau bchesn...@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
Re: CORS feature.
On Mon, Nov 28, 2011 at 02:50, Benoit Chesneau bchesn...@gmail.com wrote:
On Mon, Nov 28, 2011 at 11:38 AM, Benoit Chesneau bchesn...@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
