Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CAMWZAjnE9p2QB7zujjGqL-JiLMnbbimmuz3V-f+pW_bNeL4hng@mail.gmail.com>
References: 
 <CA+5KyPSE3BULUc7KONgx8ZqfNKW++_r8vgdhh7HLxLr0JgfM0A@mail.gmail.com>
 <CAONf+LQKjE6NVCsLKWb3wzmWOwrS2ej+_PCJS4Z=uV3hj0OtOg@mail.gmail.com>
 <CAOHkvcP0XMAFvvFhaw3azEyqBxPMhNxFwkYX+5_x52ScSaxEbg@mail.gmail.com>
 <CAMkGvyNO4GC8e+PWu8u7BpV6b4OUvXZ3v37y5kpnXdrYgn_nBA@mail.gmail.com>
 <4E371B93.8060303@kearns.net.au>
 <CAAL6JQj_u0RgDhQG95oFrQfJ3MUeRXHb+Q6d1Cc6DEBUwaE_vA@mail.gmail.com>
 <CAONf+LTt0Hmuhx8PTs_LdzzX-fHQDAhQg_kJabTQAnfnBdxZqQ@mail.gmail.com>
 <CAOHkvcNutCimOggckR3ivc2=DCAP1ZhPTC2XpnP1o_E82_Pvaw@mail.gmail.com>
 <CA+5KyPR56FpKXiQ6Zyxu0V2jwaKbOghbTZyJ10Ou=YXyyk6zhA@mail.gmail.com>
 <CAONf+LTd+qQtLBb7iXb-H_HJs4Xm+t+Bw0G4CMLCC8X=bYwdFQ@mail.gmail.com>
 <CAAL6JQhytD90Jn3f7LT-HUMVH=T5GgTEMXWzaR6kQ5BgqZGRSw@mail.gmail.com>
 <CAAL6JQjbpOD9GOu-dDDf7-1-44pANT3U=ZKaNYEBXPcX11C8pA@mail.gmail.com>
 <CAN-3CBLheiAds-L5Vps-amEHN-F-17yRqHzbzNzAq-Ev9BKa5g@mail.gmail.com>
 <CAMWZAjnE9p2QB7zujjGqL-JiLMnbbimmuz3V-f+pW_bNeL4hng@mail.gmail.com>
From: Jason Smith <jhs@iriscouch.com>
Date: Tue, 16 Aug 2011 17:21:50 +0700
Message-ID: 
 <CAN-3CBLog0VMXZYN622+3ZN=_JV09fi1UTW54rFR=-3nP6+sVQ@mail.gmail.com>
Subject: Re: to CouchApp or not to CouchApp
To: user@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8

On Tue, Aug 16, 2011 at 4:31 PM, Marcello Nuccio
<marcello.nuccio@gmail.com> wrote:
>> Things to think about regarding CouchDB security:
>>
>> * Authentication: basic, cookie, BrowserID, http vs. https
>> * Users
>> * Roles
>> * Database security objects
>> * validate_doc_update() functions in each database
>>
>> I am pretty sure that is exhaustive. The best starting point to learn
>> about CouchDB security is the "Definitive Guide" book.
>
> Thank you for audit_couchdb, Jason. It's a very useful tool.
>
> The missing piece for me is the ability to require authentication for
> read access to a couchapp, in a browser friendly way [1].
>
> Unfortunately (for me) this looks like a very rare use-case, so it
> does not raise much interest... I hope to learn some Erlang soon, to
> contribute to this issue...

If that is a rare use-case then CouchDB is doomed. I think that issue,
COUCHDB-1175, will eventually find a good solution. But, IMHO, CouchDB
does not need Erlang development! It desperately needs developer tools
and application components.

It's time to ask whether the word "couchapp" does more harm than good.
As a historical phenomenon, it is brilliant! The command-line tool is
brilliant. But the word is meaningless. It is incoherent. It
disappoints developers, setting expectations and then betraying them.

I suggest that you drop down one level of abstraction. There is HTTP;
there is CouchDB. You can fetch or store records, and use design
documents. Now think about how to "cut with the grain" to achieve your
goal.

What are your requirements?

1. You have a database which is non-public. Users must log in first,
no exceptions. Okay, so: private data.
2. You have a web page (the login prompt) which is public. Anonymous
users must access it. Okay, so: public data.

To me, that sounds like two databases, and three roles: anonymous,
normal, and developer.

1. The welcome_mat database. Effectively this is an open-source app.
  * Readable by the public: _security.readers = []
  * No updates allowed by anonymous users
  * No updates allowed by normal users
  * Yes updates if ("developer" in userCtx.roles)

2. The private_stuff database, has all of your application data and
design docs except the welcome mat.
  * Not readable by the public: _security.readers = ["normal", "developer"]
  * Updates by anonymous users is not possible [1]
  * Yes updates by normal users: ("normal" in userCtx.roles)
  * No updates by developers: ("developer" in userCtx.roles) // that
role is for software updates only

Regarding the Accept headers and the correct Content-Type: yes,
CouchDB has a bug here. It will be solved soon, but maybe you can work
around it? With the welcome_mat, you have an unlimited, independent,
full-blown web application environment to work with. You can use a
different version of jQuery compared to private_stuff. You can use no
jQuery and call XMLHttpRequest directly. You can check every browser
and OS combination manually and write case-by-case code for each
one--if necessary.

This approach has problems. You will probably be forced to use
background AJAX to determine the login status, and even to
authenticate. (That gives you the flexibility: query /private_stuff,
and anything except 200 OK indicates a bad login.) Also, when users
are already logged in to the app but their cookie expires, the
experience might suffer. On the other hand, you can move past this bug
and focus on other things.

IMHO, it doesn't matter how COUCHDB-1175 is resolved. A serious,
polished, complete application using CouchDB will probably need the
welcome_mat for many other reasons anyway. That is why I say
"contribute tools" rather than "contribute Erlang." We all need
welcome_mat, so it is worth building. This is HTTP. This is web
development. Bringing an idea to completion, nothing ever works
correctly anyway. That is the platform. Nothing ever works as planned.
It's one disappointment after another. But, if you can work through
the bugs, you've got an app on the most successful software platform
ever (the web), and IMO the most visionary web platform ever
(CouchDB). So I think it's worth it.

[1] For defense-in-depth, you could confirm this by either (1)
throwing an exception if the userCtx is anonymous, i.e. {"name":null,
"roles":[]}, and/or (2) throw an exception if the security settings
are wrong, i.e. if(secObj.readers.length == 0)

-- 
Iris Couch