My proposed answers below. In general, I think the strategy should be this:
1. If _security does not mention CORS, then use the global config. 2. If _security does mention CORS, then the global config is *completely ignored*. No merging. No surprises. 3. EXCEPT, if CORS is globally disabled, that overrides _security. On Mon, Jan 16, 2012 at 9:35 AM, Jason Smith <[email protected]> wrote: > Randall, Benoit, others: > > See http://friendpaste.com/4q1zeNUEtPFS7XbioPYYzM > > The spec says to use the global config for non-DB resources, or if a > database has no _security object. Some questions: > > 1. What if there is a _security object but nothing about CORS? For > example, I use Futon to add a DB admin. Using the "Security" section in Futon will make this happen. It will be common. Couch should be relaxing and DTRT by continuing to use the global config. > 2. What if there is a _security config *and* a global config? As I said above, mixing or merging _security with the global config will be trouble. Go with the simpler idea: if _security has CORS stuff, that is the only thing that applies. Admins can do their own merging. > 2a. Do allowed methods accumulate? E.g. _security says allow_methods > "GET, POST" and the config says allow_methods "GET, PUT". Is it (i) > "GET, POST", (ii) "GET, PUT, POST", or (iii), "GET, PUT"? The answer is (i): "GET, POST". > 2b. What about max_age? Does the _security value win? The global value > win? Or does the greater or lesser value win? The _security value wins. > 3. If CORS is working for a db, but the global config has > httpd/cors_enabled=false, what is the response for that database? This is the exception. The answer is NO CORS response. Rationale: 1. I can enable CORS globally, on every resource , using _config (no _security settings) 2. I can disable CORS globally, on every resource, using _config (no _security settings) 3. I can enable CORS individually, in _security 4. But once I do that, I have no way to disable CORS globally anymore. To disable all CORS, I have to manually check every database. Thus, the trade-off is: * Fail-safe (my proposal) * Pros: With one action, you can completely disable CORS * Cons: To get CORS on exactly one DB, you have to enable it in _config, and also enable it in _security * Fail-unsafe (_security always wins): * Pros: To get CORS on exactly one DB, just set that in _security * Cons: To disable CORS site-wide, you have to go to each DB one-by-one That is just my proposal but I am fine either way, or a third way. Thoughts? -- Iris Couch
