couchdb-marketing mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Two names: CouchDB & Couch App Server
Date Mon, 11 May 2015 16:41:20 GMT

> On 09 May 2015, at 18:49, Tim Black <> wrote:
> Hi Giovanni,
> On 05/09/2015 03:44 AM, Giovanni Lenzi wrote:
>> due to some bug I'm unable to log in at
>>> to test whether this is
>>> the case per
>>> ),
>> Can't understand... Do you get some errors? If you are trying to login to
>> frontend1 with "chatty" username, then an error is the intended chatty
>> behaviour, because he is granted on admin UI domain only(even if you can
>> relax this by modifying chatty ddoc).
> I'm sorry, I made a dumb mistake.  I failed to follow this instruction
> which you gave plainly on the site:  "use dashboard to create users
> credentials and their profiles first!"  So there is no bug.  I'm sorry I
> assumed it was a bug.
> I sent a request without the Host header (using a Chrome extension which
> permits that) and wasn't able to get any user data other than my own.  I
> wasn't able to guess the correct database name to use in the query.  I
> didn't read the code exhaustively to see if there was a place I could
> set a breakpoint maybe and find the database name.  But if I was able to
> discover that database name through the frontend, could I get other
> users' data?
>>> then *make a config option to make CouchDB require the Host header*.  It
>>> sounds easy to do, and the Host header is required in HTTP 1.1.  Or
>>> create a "default _rewrite path" configuration parameter as Giovanni
>>> described.  I expect this would make SmileUpps' CouchApp architecture
>>> secure for anyone who wants to use that architecture.
>> SmileUpps' CouchApp architecture
>>> is the only CouchApp architecture I'm aware of which has (almost)
>>> implemented document-level ACLs without some proxy server between the
>>> browser and CouchDB.
>> Ok, just want to be sure here, we are talking of same things. You are
>> referring to Smileupps way of writing apps here, right?
> I thought so, but am probably mistaken.  We humans are plagued by
> ignorance and error.  I was going on what I've read of the Chatty
> CouchApp tutorial.  I had not carefully read other things on your site
> which may mention the use of proxies.
>> Because Smileupps
>> "infrastructure" instead, heavily relies on proxies, so as far as we
>> thought it correctly, it shouldn't have such of these security concerns.
> Does Smileupps' security start in the proxies, or in CouchDB?  I thought
> there was a disagreement in this thread over whether CouchApps could be
> secured sufficiently in CouchDB alone without a proxy.

I’m confused here, too :)

Given that a proxy enforces the Host: header, how do you solve the problem
of multiple users per DB with different doc visibilities and view results
that could include data from other docs (e.g. _sum) that you weren’t
supposed to read in the first place?

The options are:
 - block views in the proxy, but I doubt you are doing this?
 - implement custom view server that creates Users x Views indexes and a
   proxy that does the correct routing.


>> Otherwise I would really appreciate, if you could share, with us, these
>> kind of security concerns confidentially. :-)
> I agree that people shouldn't post security exploits publicly, but
> rather send them to you privately.
>>> Web apps don't live on the server anymore.  They live in your phone.
>> Until today, I never really understood how security could be really
>> implemented client-side only... I always imagined this kind of apps to be
>> more consumer-oriented, where security is not such a big concern, but not
>> for companies. Do you have some pointers talking about "offline-first and
>> nobackend security"? Thanks in advance.
> I'm not any kind of authority on those things, sorry.  Hoodie's
> one-database-per-user approach permits a user to access only that data
> which filtered replications let into his own database, so presently I'm
> attempting to follow that method of implementing security/ACLs, but
> Hoodie is a backend.  I think maybe something like PGP would work for
> allowing security to be governed from the client side completely.  But
> PGP's always had trouble achieving adoption among ordinary nontechnical
> users, so I don't know whether it could be made accessible in a true
> peer-to-peer social network like Monocles (which also was still written
> to require a relatively persistent server; I'd like to see one written
> which doesn't require a server very often, or, in other words, which
> puts the server in the browser, and maintains a list of active known
> peers which all network with each other, more like Bittorrent; nearly
> like  Wuala's encryption tree would be an interesting
> model to follow).
> Tim

Professional Support for Apache CouchDB:

View raw message