configurable CORS on login resources

[jchris]

The first implementation of CORS support was conservative about enabling login via CORS.

However most apps will want to enable login from CORS hosts, simply because that is where the UI is located. So we need to make an option to enable CORS for logins.

I think this could be another field in the CORS config object, named sessionOrigin which would have an array of string origins as it's value.

For sugar, we could also have the option of true in cases where there will be many origins and all should have login access.

This config would then be consulted in places like this:

sync_gateway/src/github.com/couchbase/sync_gateway/rest/facebook.go

Line 29 in 36ac90f

if len(h.rq.Header["Origin"]) > 0 {

I'm labeling this a bug because CORS is not useful for anything besides toy apps without this. Tag @jamiltz b/c he's about to run into this.

N.B. It would be easy to convince me that we should just remove the protection from the session endpoints, and if CORS is turned on at all, it's turned on for session stuff too.

[jchris]

Link to example CORS config so you don't have to dig it up yourself https://github.com/couchbase/sync_gateway/blob/master/examples/cors_admin_party.json

[jamesnocentini]

While working on a Todo app with facebook authentication and CORS enabled on SG I was getting back a No CORS response on /db/_facebook which is expected since CORS is currently always disabled on login endpoints. To log users in, @jchris suggested to perform the login on the same origin as SG by hosting an html page as attachment (e.g. /db/loginpage/index.html).

On the app, the user flow would be: webappdomain.com -> sgdomain.com/db/loginpage/index.html -> webappdomain.com.

This requires the attachment to be publicly accessible. SG could provide an api in the config file to allow a set of docs to be public for this use case.

[jchris]

@jamiltz am I right that you'd prefer to just be able to turn on CORS access for login, instead of some kinda HTML hack?

[jamesnocentini]

@jchris Having CORS enabled with login would be even easier yes but I'm not sure what the security implications would be.

Then I'm guessing web apps would have to set the .withCredentials flag to true to send the SG cookie in authed requests? (https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Requests_with_credentials)

[jchris]

I think in the case of a FB token, the security situation is clear b/c they make login apps use an app id that matches an origin. But for user/pass sessions it's harder b/c you don't want just any site to put up a UI that accepts user passwords.

[jchris]

I'm in the code implementing now, and that last point makes me think we might want different policy for different endpoints. This is one of those things that will probably get controlled by a proxy in a deployed app, but SG should ship with something workable for getting started purposes.