couchdb-marketing mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: SmileUpps Features (Was: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas))
Date Wed, 06 May 2015 09:51:53 GMT

> On 06 May 2015, at 07:49, Johs Ensby <johs@b2w.com> wrote:
> 
> Jan and Giovanni,
> I am afraid I am dumbing down the discussion here (Giovanni, sorry for not studying your
docs in detail yet), but isn’t this very basic?
> a vhost point all requests directly to the _rewrite that is used to manage security
> the _rewrite decides what to forward to the databases (with or without preset parameters
in the rewrite rule)

When I send a request without a Host: header, then the vhost mechanism doesn’t kick in and
I can access the full CouchDB server. There is no “default vhost” setting in CouchDB.

Cloudant uses a different vhost system that I’m not familiar with.

Best
Jan
--


> 
> I have used Cloudant for hosting, so my experience is based on the following setup procedure
> define vhost, point this to a _rewrite of a selected ddoc
> define access to each db based on where the traffic comes from, differentiate access
levels by using more than one vhost, e.g. editor.mydomain.com <http://editor.domain.com/>
and www.mydomain.com
> use one _rewrite as your API, strap it down as much as you want or
> use one _rewrite per access level (vhost)
> open up for rewrite to ../../../etc if you need to reach multiple dbs from same _rewrite
> create views for commonly requested subsets of data
> do the fine grade filtering in lists
> 
> As for access control in the list (row by row) we have a req.userCtx.roles object with
info coming from authenication via LlinkedIn to filter out data.
> There is a huge performance penalty for having to filter views in the list, of course,
but the combination of views and filtering in a list serves a lot of purposes well as long
as you think of your vhosts and _rewrites as your CouchApp API.
> 
> 
> Johs
> 
>> On 05 May 2015, at 19:08, Jan Lehnardt <jan@apache.org> wrote:
>> 
>>> I still haven't heard of a single path for exploit, but ok...
>> 
>> I make a GET request to http://<ip-address>:<port>/database/_all_docs?include_docs=true
authenticated as one of your users, with your couchapp in it. In CouchDB parlance, I get all
docs if I have access to the db. There is no way of making CouchDB only return “my” documents
and not documents from other users. There is also no way of forcing me another route. What
happens on your system?
> 

-- 
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/


Mime
View raw message