On Mon, Nov 28, 2011 at 9:03 PM, Randall Leeds <[email protected]> wrote: > On Mon, Nov 28, 2011 at 02:50, Benoit Chesneau <[email protected]> wrote: >> On Mon, Nov 28, 2011 at 11:38 AM, Benoit Chesneau <[email protected]> >> 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
