CORS question: interaction of global and local config

[Jason Smith <jh...@iriscouch.com>]

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.

2. What if there is a _security config *and* a global config?

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"?

2b. What about max_age? Does the _security value win? The global value
win? Or does the greater or lesser value win?

3. If CORS is working for a db, but the global config has
httpd/cors_enabled=false, what is the response for that database?

-- 
Iris Couch

Re: CORS question: interaction of global and local config

[Jason Smith <jh...@iriscouch.com>]

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 <jh...@iriscouch.com> 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