couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <>
Subject Re: CORS question: interaction of global and local config
Date Mon, 16 Jan 2012 02:52:52 GMT
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 <> wrote:
> Randall, Benoit, others:
> See
> 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

> 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

View raw message