couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: to CouchApp or not to CouchApp
Date Tue, 16 Aug 2011 11:01:48 GMT
"Regarding the Accept headers and the correct Content-Type: yes,
CouchDB has a bug here."

The discussion on 1175 has reached a dead-end, it seems. I would
rather revert to the 1.0.x behavior given the feedback for 1.1.0. I
had hoped to 'adopt the standard' specified in RFC 2616 but, it turns
out, that's not going to work either. There are popular browsers (IE
still being inexplicably popular) that send poor Accept headers, so we
cannot resolve this completely by following teh rulez.

My revised proposal was to send text/html (and 302's) in all cases
except for the very specific case where the Accept header is exactly
one item and that item is 'application/json'. All programmatic calls
can meet that (libraries incapable of this are de facto poor
libraries), and the ambiguity is vanquished.


On 16 August 2011 11:21, Jason Smith <> wrote:
> On Tue, Aug 16, 2011 at 4:31 PM, Marcello Nuccio
> <> 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

View raw message