You are viewing a plain text version of this content. The canonical link for it is here.
Posted to marketing@couchdb.apache.org by Jan Lehnardt <ja...@apache.org> on 2015/05/05 13:42:14 UTC
SmileUpps Features (Was: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas))
> On 05 May 2015, at 13:17, Giovanni Lenzi <g....@smileupps.com> wrote:
>
>> How do you do per-doc or per-attachment ACL? Those are not core CouchDB
> features.
>
> per-doc:
> - read : https://www.smileupps.com/couchapp-tutorial-chatty-read-api
That looks like you are using a changes filter. A client has to opt into that. what if a client calls changes without the filter?
> - write: https://www.smileupps.com/couchapp-tutorial-chatty-write-api
>
> per-attachments: a tutorial will come.. however
> - write: same method used in
> https://www.smileupps.com/couchapp-tutorial-chatty-write-api
> - reads: through unguessable ids, which is industry common practice
>
> all of the above can be seriously enhanced with filtered changes and some
> minor improvements to rewriting engine module.
>
>
>
> 2015-05-05 13:01 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
>
>>
>>> On 05 May 2015, at 12:54, Giovanni Lenzi <g....@smileupps.com> wrote:
>>>
>>> I think it's a timing problem.. probably Couchapps were simply not mature
>>> enough some years ago.. but nowadays their potential has increased a lot,
>>> under every aspect.
>>>
>>> IMHO they are even one of the best way to implement granular server-side
>>> security.
>>>
>>> - security: server-side read and write ACLS are a reality(
>>> https://www.smileupps.com/couchapp-tutorial-chatty)
>>> - filtered changes from RCouch will improve security even further
>>> - probably, some minor tweaks to the rewriting engine module can easily
>>> add ACL at view level, so improving performance on #3
>>> - ACL for _attachments is already possible. We have a tutorial
>> scheduled
>>> on that
>>
>> How do you do per-doc or per-attachment ACL? Those are not core CouchDB
>> features.
>>
>>
>>>
>>> - background events are a reality too and they enable Couchapps to
>> perform
>>> any kind of background REST events:
>>> - send email, SMS, payments, scheduled backups.. and so on.. just by
>>> interacting with the database
>>> - all these jobs can eventually be packed into single-feature-ready
>>> couchapps: e.g. "do you need stripe payments on your website?".. just
>>> download the stripe couchapp!
>>> - the daemon is opensource and implemented in node.js,
>>> https://www.smileupps.com/couch-daemon-triggerjob ... but it would be
>> great
>>> ported to erlang
>>>
>>> I agree with ermouth a lot can still be done around tooling, performance
>>> and scalability (do you think bigcouch can eventually help us on this
>>> too?), but I think leaving Couchapps could be really a great error.
>>>
>>>
>>> 2015-05-05 11:49 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
>>>
>>>>
>>>>> On 05 May 2015, at 11:08, Andy Wenk <an...@apache.org> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Jan thanks for raising this important topic!
>>>>>
>>>>> As I had been around and participated when JChris, Jan and others
>> started
>>>>> CouchApps and Benoit took over the work, I am a bit sad, that CouchApps
>>>>> started to confuse people. And yes it is true, they are limited but
>> have
>>>>> their place in the history of CouchDB. Far more, it can easily be seen
>> as
>>>>> the evolutionary basis for Hoodie and that is a good thing imho.
>>>>>
>>>>> We should give CouchApps a place to live in the CouchDB ecosystem (not
>>>>> meant technically). So my proposal is to reactivate couchapp.org and
>>>> write
>>>>> one page with info about
>>>>>
>>>>> * what CouchApps are
>>>>> * how one can create one (links to doku)
>>>>> * what alternatives there are (kanso, hoodie ...)
>>>>>
>>>>> Furthermore we should include a link on couchdb.org to couchapp.org.
>>>>>
>>>>> I think it would be wrong to leave people still in the dark even though
>>>>> nowadays we think, CouchApps is not the way one should create a WebApp
>>>>> based on CouchDB (and I don't think the approaches to create CouchApps
>>>> was
>>>>> foolish Jan ;-)). It is our responsibility to clarify what CouchApps
>> are
>>>>> and why one should move forward to sth. better. With clarification
>> comes
>>>>> clarity
>>>>
>>>> Thanks Andy! — I’m all for the things you mention, once we figure out
>> how
>>>> the CouchApps story fits into the larger CouchDB story without confusing
>>>> anyone.
>>>>
>>>> What’s your take on that? :)
>>>>
>>>> * * *
>>>>
>>>> Also, I think we shouldn’t be afraid to make CouchApp’s place in
>> CouchDB’s
>>>> history clear in terms of “This was an idea of its time. Today, we think
>>>> differently. RIP CouchApps”.
>>>>
>>>>
>>>> Best
>>>> Jan
>>>> --
>>>>
>>>>>
>>>>> All the best
>>>>>
>>>>> Andy
>>>>>
>>>>>
>>>>> On 5 May 2015 at 10:54, Jan Lehnardt <ja...@apache.org> wrote:
>>>>>
>>>>>> It seems we have a separate discussion going on here, so I forked the
>>>>>> thread.
>>>>>>
>>>>>> I’ve seen these two sides ever since we invented CouchApps:
>>>>>>
>>>>>> Pro:
>>>>>> - CouchApps are amazingly simple
>>>>>> - CouchDB as an app server is a great idea, I don’t need to run any
>>>> other
>>>>>> infrastructure
>>>>>> - this is the future of web development
>>>>>> - couchapp* is a great tool to manage design docs
>>>>>>
>>>>>> (*or erica… etc.)
>>>>>>
>>>>>> Con:
>>>>>> - the concept of compiling design docs is confusing
>>>>>> - even when they get it, they are confused that they need a third
>>>> party
>>>>>> tool called `couchapp` to do so, because the documentation talks about
>>>>>> building full apps in CouchDB, they have an external app and just want
>>>> to
>>>>>> use CouchDB as a database, but couchapp is still the tool they need.
>>>>>> - the tooling is poor
>>>>>> - the tooling is all third-party
>>>>>> - they can only cover a very limited use-case
>>>>>> - CouchApps are the only way to use CouchDB
>>>>>>
>>>>>>
>>>>>> I see a number of people being passionate about CouchApps and I
>> believe
>>>>>> their enthusiasm is warranted, CouchApps are a neat idea.
>>>>>>
>>>>>> But I also see a greater number of people being confused by CouchApps
>>>> and
>>>>>> in turn by CouchDB.
>>>>>>
>>>>>> That is not a good situation.
>>>>>>
>>>>>> Let’s think about how (and if) we can fit the CouchApp story into a
>>>>>> coherent CouchDB story.
>>>>>>
>>>>>> A prerequisite for that is having a coherent CouchDB story, which we
>>>> don’t
>>>>>> have fully finalised yet, but we have talked about extensively, and
>> the
>>>>>> consensus is around the “Data where you need it” narrative that
>>>> emphasises
>>>>>> replication between CouchDB instances and other projects that speak
>> the
>>>>>> replication protocol (especially PouchDB and TouchDB).
>>>>>>
>>>>>> How do CouchApps fit into that narrative?
>>>>>>
>>>>>>
>>>>>> * * *
>>>>>>
>>>>>> (Personal view alert: this is just to give some more background on my
>>>> own
>>>>>> position, this isn’t meant as a basis for discussion)
>>>>>>
>>>>>> I’m personally conflicted. When we set out to develop CouchApps, we
>>>>>> thought we are inventing a new paradigm for how to build the web, and
>>>>>> everybody would follow us, because that would enable a true p2p web.
>>>> That
>>>>>> didn’t happen and probably was a little foolish of us :D
>>>>>>
>>>>>> Technically, that would have meant CouchApps had to grow a lot more
>> and
>>>> I
>>>>>> realised quickly that CouchDB is not the right place to grow such a
>>>> thing.
>>>>>> In addition, there are various fully fledged web frameworks already
>> and
>>>>>> CouchApps could never really compete in terms of person-power and
>>>> attention.
>>>>>>
>>>>>> That all led me to re-evaluate the whole value proposition, when
>> things
>>>>>> like PouchDB came up and the browser became a decent application
>>>>>> development platform. That whole thinking led to the creation of
>> Hoodie
>>>> (
>>>>>> http://hood.ie), which started out with the code name CANG (Couch
>> Apps
>>>>>> Next Generation), where we liked some of the core ideas of CouchApps,
>>>> but
>>>>>> wanted to address the limitations that would stifle their adoption.
>>>> Hoodie
>>>>>> embraces browser-to-server sync to allow fully offline apps, it allows
>>>>>> all-javascript-all-json development on the front- and back-end. It
>> uses
>>>> the
>>>>>> database-per-user and the _changes-feed-as-async-worker paradigms and
>>>> it is
>>>>>> all wrapped into a package that is *really* easy to understand and get
>>>>>> started with. Hoodie, unlike CouchApps, does have a fighting chance of
>>>>>> making CouchDB’s unique features (replication, _changes) available
>> for a
>>>>>> larger population and I’m infinitely excited about that.
>>>>>>
>>>>>> * * *
>>>>>>
>>>>>> All that doesn’t mean, however, that CouchApps don’t have their place,
>>>> but
>>>>>> again, I’m not sure where that place is and the place it currently has
>>>>>> seems to negatively affect CouchDB, so I’d like for this list to think
>>>> and
>>>>>> talk about all that for a bit.
>>>>>>
>>>>>> How can we make it that CouchApps strengthen CouchDB and not weaken it
>>>> by
>>>>>> adding confusion?
>>>>>>
>>>>>> How do CouchApps fit into the CouchDB story?
>>>>>>
>>>>>>
>>>>>> Best
>>>>>> Jan
>>>>>> --
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 05 May 2015, at 08:45, ermouth <er...@gmail.com> wrote:
>>>>>>>
>>>>>>>> CouchDB-killing answers
>>>>>>>
>>>>>>> Well... When someone says couchapps is silver bullet – I say ‘No’
>> and I
>>>>>> can
>>>>>>> prove it. Couchapps have a lot, A LOT of problems, and some of them
>> can
>>>>>> not
>>>>>>> be solved inside CouchDB. For example, try to implement ACL for
>>>>>> attachments
>>>>>>> or try to scale couchapp. You just can‘t do it in reasonable way.
>>>>>>>
>>>>>>> I know several engineers who tried out couchapps – and left CouchDB
>>>>>>> forever. Not because CouchDB itself, but because couchapps. O‘Reilly
>>>> said
>>>>>>> it‘s a silver bullet, others said – and what we have? Sloppy and
>>>>>>> hard-to-debug architecture, that does not scale, has no tooling and a
>>>> lot
>>>>>>> of security issues.
>>>>>>>
>>>>>>> You gonna solve architecture problems with positive posts?
>>>>>>>
>>>>>>> What I want to say – there is no need to lie and say couchapps are
>>>> great.
>>>>>>> Because they are not.
>>>>>>>
>>>>>>>> would you like to write down some of your positive:-)) experiences?
>>>>>>>
>>>>>>> http://ermouth.livejournal.com/tag/couchdb – sorry, Russian
>> language.
>>>>>>>
>>>>>>> ermouth
>>>>>>
>>>>>> --
>>>>>> Professional Support for Apache CouchDB:
>>>>>> http://www.neighbourhood.ie/couchdb-support/
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Andy Wenk
>>>>> Hamburg - Germany
>>>>> RockIt!
>>>>>
>>>>> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588
>>>>>
>>>>> https://people.apache.org/keys/committer/andywenk.asc
>>>>
>>>> --
>>>> Professional Support for Apache CouchDB:
>>>> http://www.neighbourhood.ie/couchdb-support/
>>>>
>>>>
>>
>> --
>> Professional Support for Apache CouchDB:
>> http://www.neighbourhood.ie/couchdb-support/
>>
>>
--
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/
Re: SmileUpps Features (Was: How do CouchApps fit into the CouchDB
story? (Was: CouchDB Articles, Pills and Tutorials Ideas))
Posted by Giovanni Lenzi <g....@smileupps.com>.
The full couchapp is also on github:
https://github.com/Smileupps/couchapp-chatty
2015-05-05 15:14 GMT+02:00 Giovanni Lenzi <g....@smileupps.com>:
> > That happens in a proxy outside of CouchDB then?
>
> No, it happens in the changes filter of the design document.
>
>
>
Re: SmileUpps Features (Was: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas))
Posted by Jan Lehnardt <ja...@apache.org>.
> On 06 May 2015, at 07:49, Johs Ensby <jo...@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 <ja...@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/
Re: SmileUpps Features (Was: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas))
Posted by Johs Ensby <jo...@b2w.com>.
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)
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 <ja...@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?
Re: SmileUpps Features (Was: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas))
Posted by Jan Lehnardt <ja...@apache.org>.
> On 05 May 2015, at 18:53, Giovanni Lenzi <g....@smileupps.com> wrote:
>
>> I found a massive security concern
>
> 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?
> everyone will remain with his own convinctions
I’m trying to find out if I misunderstand a system that I designed. I must be missing something. Are you not saying you can make it so multiple users can share one database and only get r/w access to their own docs?
Best
Jan
--
>
> Thanks for your patience too
>
>
> 2015-05-05 17:09 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
>
>>
>>> On 05 May 2015, at 16:36, Giovanni Lenzi <g....@smileupps.com> wrote:
>>>
>>>> otherwise, again, the system is insecure (I helped build it that way).
>>> To tell the truth, with handlers renaming or as soon as an attacker
>> doesn't
>>> know your db name, the system can still be secured withouth any proxy.
>> However,
>>> if proxy is really a concern, a fix to use CouchDB only, could eventually
>>> be creating a new "default _rewrite path" parameter within couchdb
>>> configuration, to be used as "default path" in case of request without or
>>> with an incorrect "Host Header"
>>>
>>> Jan, trust me... All I'm doing here is to bring help with marketing,
>>> tutorials and CouchDB improvements... I hope this can be recognized
>>
>> No worries, I 100% recognise your efforts.
>>
>> Thank you for being patient with me.
>>
>> My only concern was with understanding how your particular flavour of
>> CouchApp
>> works and I think I found a massive security concern. That’s why I won’t be
>> advocating for this particular solution (not saying it can’t be, but it
>> isn’t
>> today).
>>
>> With that out of the way, let’s get back to the story part of this
>> discussion.
>>
>> Thanks
>> Jan
>> --
>>
>>
>>>
>>>
>>> 2015-05-05 15:57 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
>>>
>>>>
>>>>> On 05 May 2015, at 15:50, Giovanni Lenzi <g....@smileupps.com>
>> wrote:
>>>>>
>>>>>> CouchDB has no way of blocking requests to _changes that have no
>> filter
>>>>> parameter
>>>>> Why? _rewrite handler is used to allow only requests complying with
>> your
>>>>> api, and therefore preventing requests to changes withouth a filter.
>> You
>>>>> can have a look to rewrites.json file for this.
>>>>>
>>>>> I agree proxy is a best practice as a load balancer and to forward only
>>>>> requests to allowed vhosts, like Smileupps, Iriscouch or Cloudant all
>> are
>>>>> doing, even if it's not strictly mandatory for security.
>>>>>
>>>>> Anyway, I was not interested here, in raising this kind of technical
>>>>> discussion. My starting e-mail only wanted to be constructive, by
>>>> proposing
>>>>> a way to push content around CouchDB and Couchapps, to help everyone
>>>>> understand what they really can and cannot do.
>>>>
>>>> I’m sorry to derail this, but I want to make sure I understand your
>> system
>>>> before I can argue for or against your claims :)
>>>>
>>>> Your point that CouchApps can be a platform is well taken, thank you for
>>>> that!
>>>>
>>>> You equally can’t force a client to use a _request handler, only if you
>>>> block requests without a Host: header in a proxy in front of CouchDB,
>>>> otherwise, again, the system is insecure (I helped build it that way).
>>>>
>>>> Best
>>>> Jan
>>>> --
>>>>
>>>>
>>>>>
>>>>>
>>>>> 2015-05-05 15:21 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
>>>>>
>>>>>>
>>>>>>> On 05 May 2015, at 15:14, Giovanni Lenzi <g....@smileupps.com>
>>>> wrote:
>>>>>>>
>>>>>>>> That happens in a proxy outside of CouchDB then?
>>>>>>>
>>>>>>> No, it happens in the changes filter of the design document.
>>>>>>
>>>>>> You cannot force a client to use a filter. CouchDB has no way of
>>>> blocking
>>>>>> requests to _changes that have no filter parameter. If you are not
>> doing
>>>>>> that in a proxy, your system is not secure.
>>>>>>
>>>>>> Best
>>>>>> Jan
>>>>>> --
>>>>>> Professional Support for Apache CouchDB:
>>>>>> http://www.neighbourhood.ie/couchdb-support/
>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Professional Support for Apache CouchDB:
>>>> http://www.neighbourhood.ie/couchdb-support/
>>>>
>>>>
>>
>> --
>> Professional Support for Apache CouchDB:
>> http://www.neighbourhood.ie/couchdb-support/
>>
>>
--
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/
Re: SmileUpps Features (Was: How do CouchApps fit into the CouchDB
story? (Was: CouchDB Articles, Pills and Tutorials Ideas))
Posted by Giovanni Lenzi <g....@smileupps.com>.
> I found a massive security concern
I still haven't heard of a single path for exploit, but ok... everyone will
remain with his own convinctions
Thanks for your patience too
2015-05-05 17:09 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
>
> > On 05 May 2015, at 16:36, Giovanni Lenzi <g....@smileupps.com> wrote:
> >
> >> otherwise, again, the system is insecure (I helped build it that way).
> > To tell the truth, with handlers renaming or as soon as an attacker
> doesn't
> > know your db name, the system can still be secured withouth any proxy.
> However,
> > if proxy is really a concern, a fix to use CouchDB only, could eventually
> > be creating a new "default _rewrite path" parameter within couchdb
> > configuration, to be used as "default path" in case of request without or
> > with an incorrect "Host Header"
> >
> > Jan, trust me... All I'm doing here is to bring help with marketing,
> > tutorials and CouchDB improvements... I hope this can be recognized
>
> No worries, I 100% recognise your efforts.
>
> Thank you for being patient with me.
>
> My only concern was with understanding how your particular flavour of
> CouchApp
> works and I think I found a massive security concern. That’s why I won’t be
> advocating for this particular solution (not saying it can’t be, but it
> isn’t
> today).
>
> With that out of the way, let’s get back to the story part of this
> discussion.
>
> Thanks
> Jan
> --
>
>
> >
> >
> > 2015-05-05 15:57 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
> >
> >>
> >>> On 05 May 2015, at 15:50, Giovanni Lenzi <g....@smileupps.com>
> wrote:
> >>>
> >>>> CouchDB has no way of blocking requests to _changes that have no
> filter
> >>> parameter
> >>> Why? _rewrite handler is used to allow only requests complying with
> your
> >>> api, and therefore preventing requests to changes withouth a filter.
> You
> >>> can have a look to rewrites.json file for this.
> >>>
> >>> I agree proxy is a best practice as a load balancer and to forward only
> >>> requests to allowed vhosts, like Smileupps, Iriscouch or Cloudant all
> are
> >>> doing, even if it's not strictly mandatory for security.
> >>>
> >>> Anyway, I was not interested here, in raising this kind of technical
> >>> discussion. My starting e-mail only wanted to be constructive, by
> >> proposing
> >>> a way to push content around CouchDB and Couchapps, to help everyone
> >>> understand what they really can and cannot do.
> >>
> >> I’m sorry to derail this, but I want to make sure I understand your
> system
> >> before I can argue for or against your claims :)
> >>
> >> Your point that CouchApps can be a platform is well taken, thank you for
> >> that!
> >>
> >> You equally can’t force a client to use a _request handler, only if you
> >> block requests without a Host: header in a proxy in front of CouchDB,
> >> otherwise, again, the system is insecure (I helped build it that way).
> >>
> >> Best
> >> Jan
> >> --
> >>
> >>
> >>>
> >>>
> >>> 2015-05-05 15:21 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
> >>>
> >>>>
> >>>>> On 05 May 2015, at 15:14, Giovanni Lenzi <g....@smileupps.com>
> >> wrote:
> >>>>>
> >>>>>> That happens in a proxy outside of CouchDB then?
> >>>>>
> >>>>> No, it happens in the changes filter of the design document.
> >>>>
> >>>> You cannot force a client to use a filter. CouchDB has no way of
> >> blocking
> >>>> requests to _changes that have no filter parameter. If you are not
> doing
> >>>> that in a proxy, your system is not secure.
> >>>>
> >>>> Best
> >>>> Jan
> >>>> --
> >>>> Professional Support for Apache CouchDB:
> >>>> http://www.neighbourhood.ie/couchdb-support/
> >>>>
> >>>>
> >>
> >> --
> >> Professional Support for Apache CouchDB:
> >> http://www.neighbourhood.ie/couchdb-support/
> >>
> >>
>
> --
> Professional Support for Apache CouchDB:
> http://www.neighbourhood.ie/couchdb-support/
>
>
Re: SmileUpps Features (Was: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas))
Posted by Jan Lehnardt <ja...@apache.org>.
> On 05 May 2015, at 16:36, Giovanni Lenzi <g....@smileupps.com> wrote:
>
>> otherwise, again, the system is insecure (I helped build it that way).
> To tell the truth, with handlers renaming or as soon as an attacker doesn't
> know your db name, the system can still be secured withouth any proxy. However,
> if proxy is really a concern, a fix to use CouchDB only, could eventually
> be creating a new "default _rewrite path" parameter within couchdb
> configuration, to be used as "default path" in case of request without or
> with an incorrect "Host Header"
>
> Jan, trust me... All I'm doing here is to bring help with marketing,
> tutorials and CouchDB improvements... I hope this can be recognized
No worries, I 100% recognise your efforts.
Thank you for being patient with me.
My only concern was with understanding how your particular flavour of CouchApp
works and I think I found a massive security concern. That’s why I won’t be
advocating for this particular solution (not saying it can’t be, but it isn’t
today).
With that out of the way, let’s get back to the story part of this discussion.
Thanks
Jan
--
>
>
> 2015-05-05 15:57 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
>
>>
>>> On 05 May 2015, at 15:50, Giovanni Lenzi <g....@smileupps.com> wrote:
>>>
>>>> CouchDB has no way of blocking requests to _changes that have no filter
>>> parameter
>>> Why? _rewrite handler is used to allow only requests complying with your
>>> api, and therefore preventing requests to changes withouth a filter. You
>>> can have a look to rewrites.json file for this.
>>>
>>> I agree proxy is a best practice as a load balancer and to forward only
>>> requests to allowed vhosts, like Smileupps, Iriscouch or Cloudant all are
>>> doing, even if it's not strictly mandatory for security.
>>>
>>> Anyway, I was not interested here, in raising this kind of technical
>>> discussion. My starting e-mail only wanted to be constructive, by
>> proposing
>>> a way to push content around CouchDB and Couchapps, to help everyone
>>> understand what they really can and cannot do.
>>
>> I’m sorry to derail this, but I want to make sure I understand your system
>> before I can argue for or against your claims :)
>>
>> Your point that CouchApps can be a platform is well taken, thank you for
>> that!
>>
>> You equally can’t force a client to use a _request handler, only if you
>> block requests without a Host: header in a proxy in front of CouchDB,
>> otherwise, again, the system is insecure (I helped build it that way).
>>
>> Best
>> Jan
>> --
>>
>>
>>>
>>>
>>> 2015-05-05 15:21 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
>>>
>>>>
>>>>> On 05 May 2015, at 15:14, Giovanni Lenzi <g....@smileupps.com>
>> wrote:
>>>>>
>>>>>> That happens in a proxy outside of CouchDB then?
>>>>>
>>>>> No, it happens in the changes filter of the design document.
>>>>
>>>> You cannot force a client to use a filter. CouchDB has no way of
>> blocking
>>>> requests to _changes that have no filter parameter. If you are not doing
>>>> that in a proxy, your system is not secure.
>>>>
>>>> Best
>>>> Jan
>>>> --
>>>> Professional Support for Apache CouchDB:
>>>> http://www.neighbourhood.ie/couchdb-support/
>>>>
>>>>
>>
>> --
>> Professional Support for Apache CouchDB:
>> http://www.neighbourhood.ie/couchdb-support/
>>
>>
--
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/
Re: SmileUpps Features (Was: How do CouchApps fit into the CouchDB
story? (Was: CouchDB Articles, Pills and Tutorials Ideas))
Posted by Giovanni Lenzi <g....@smileupps.com>.
> otherwise, again, the system is insecure (I helped build it that way).
To tell the truth, with handlers renaming or as soon as an attacker doesn't
know your db name, the system can still be secured withouth any proxy. However,
if proxy is really a concern, a fix to use CouchDB only, could eventually
be creating a new "default _rewrite path" parameter within couchdb
configuration, to be used as "default path" in case of request without or
with an incorrect "Host Header"
Jan, trust me... All I'm doing here is to bring help with marketing,
tutorials and CouchDB improvements... I hope this can be recognized
2015-05-05 15:57 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
>
> > On 05 May 2015, at 15:50, Giovanni Lenzi <g....@smileupps.com> wrote:
> >
> >> CouchDB has no way of blocking requests to _changes that have no filter
> > parameter
> > Why? _rewrite handler is used to allow only requests complying with your
> > api, and therefore preventing requests to changes withouth a filter. You
> > can have a look to rewrites.json file for this.
> >
> > I agree proxy is a best practice as a load balancer and to forward only
> > requests to allowed vhosts, like Smileupps, Iriscouch or Cloudant all are
> > doing, even if it's not strictly mandatory for security.
> >
> > Anyway, I was not interested here, in raising this kind of technical
> > discussion. My starting e-mail only wanted to be constructive, by
> proposing
> > a way to push content around CouchDB and Couchapps, to help everyone
> > understand what they really can and cannot do.
>
> I’m sorry to derail this, but I want to make sure I understand your system
> before I can argue for or against your claims :)
>
> Your point that CouchApps can be a platform is well taken, thank you for
> that!
>
> You equally can’t force a client to use a _request handler, only if you
> block requests without a Host: header in a proxy in front of CouchDB,
> otherwise, again, the system is insecure (I helped build it that way).
>
> Best
> Jan
> --
>
>
> >
> >
> > 2015-05-05 15:21 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
> >
> >>
> >>> On 05 May 2015, at 15:14, Giovanni Lenzi <g....@smileupps.com>
> wrote:
> >>>
> >>>> That happens in a proxy outside of CouchDB then?
> >>>
> >>> No, it happens in the changes filter of the design document.
> >>
> >> You cannot force a client to use a filter. CouchDB has no way of
> blocking
> >> requests to _changes that have no filter parameter. If you are not doing
> >> that in a proxy, your system is not secure.
> >>
> >> Best
> >> Jan
> >> --
> >> Professional Support for Apache CouchDB:
> >> http://www.neighbourhood.ie/couchdb-support/
> >>
> >>
>
> --
> Professional Support for Apache CouchDB:
> http://www.neighbourhood.ie/couchdb-support/
>
>
Re: SmileUpps Features (Was: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas))
Posted by Jan Lehnardt <ja...@apache.org>.
> On 05 May 2015, at 15:50, Giovanni Lenzi <g....@smileupps.com> wrote:
>
>> CouchDB has no way of blocking requests to _changes that have no filter
> parameter
> Why? _rewrite handler is used to allow only requests complying with your
> api, and therefore preventing requests to changes withouth a filter. You
> can have a look to rewrites.json file for this.
>
> I agree proxy is a best practice as a load balancer and to forward only
> requests to allowed vhosts, like Smileupps, Iriscouch or Cloudant all are
> doing, even if it's not strictly mandatory for security.
>
> Anyway, I was not interested here, in raising this kind of technical
> discussion. My starting e-mail only wanted to be constructive, by proposing
> a way to push content around CouchDB and Couchapps, to help everyone
> understand what they really can and cannot do.
I’m sorry to derail this, but I want to make sure I understand your system
before I can argue for or against your claims :)
Your point that CouchApps can be a platform is well taken, thank you for that!
You equally can’t force a client to use a _request handler, only if you
block requests without a Host: header in a proxy in front of CouchDB,
otherwise, again, the system is insecure (I helped build it that way).
Best
Jan
--
>
>
> 2015-05-05 15:21 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
>
>>
>>> On 05 May 2015, at 15:14, Giovanni Lenzi <g....@smileupps.com> wrote:
>>>
>>>> That happens in a proxy outside of CouchDB then?
>>>
>>> No, it happens in the changes filter of the design document.
>>
>> You cannot force a client to use a filter. CouchDB has no way of blocking
>> requests to _changes that have no filter parameter. If you are not doing
>> that in a proxy, your system is not secure.
>>
>> Best
>> Jan
>> --
>> Professional Support for Apache CouchDB:
>> http://www.neighbourhood.ie/couchdb-support/
>>
>>
--
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/
Re: SmileUpps Features (Was: How do CouchApps fit into the CouchDB
story? (Was: CouchDB Articles, Pills and Tutorials Ideas))
Posted by Giovanni Lenzi <g....@smileupps.com>.
> CouchDB has no way of blocking requests to _changes that have no filter
parameter
Why? _rewrite handler is used to allow only requests complying with your
api, and therefore preventing requests to changes withouth a filter. You
can have a look to rewrites.json file for this.
I agree proxy is a best practice as a load balancer and to forward only
requests to allowed vhosts, like Smileupps, Iriscouch or Cloudant all are
doing, even if it's not strictly mandatory for security.
Anyway, I was not interested here, in raising this kind of technical
discussion. My starting e-mail only wanted to be constructive, by proposing
a way to push content around CouchDB and Couchapps, to help everyone
understand what they really can and cannot do.
2015-05-05 15:21 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
>
> > On 05 May 2015, at 15:14, Giovanni Lenzi <g....@smileupps.com> wrote:
> >
> >> That happens in a proxy outside of CouchDB then?
> >
> > No, it happens in the changes filter of the design document.
>
> You cannot force a client to use a filter. CouchDB has no way of blocking
> requests to _changes that have no filter parameter. If you are not doing
> that in a proxy, your system is not secure.
>
> Best
> Jan
> --
> Professional Support for Apache CouchDB:
> http://www.neighbourhood.ie/couchdb-support/
>
>
Re: SmileUpps Features (Was: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas))
Posted by Jan Lehnardt <ja...@apache.org>.
> On 05 May 2015, at 15:14, Giovanni Lenzi <g....@smileupps.com> wrote:
>
>> That happens in a proxy outside of CouchDB then?
>
> No, it happens in the changes filter of the design document.
You cannot force a client to use a filter. CouchDB has no way of blocking requests to _changes that have no filter parameter. If you are not doing that in a proxy, your system is not secure.
Best
Jan
--
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/
Re: SmileUpps Features (Was: How do CouchApps fit into the CouchDB
story? (Was: CouchDB Articles, Pills and Tutorials Ideas))
Posted by Giovanni Lenzi <g....@smileupps.com>.
> That happens in a proxy outside of CouchDB then?
No, it happens in the changes filter of the design document.
Re: SmileUpps Features (Was: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas))
Posted by Jan Lehnardt <ja...@apache.org>.
> On 05 May 2015, at 14:18, Giovanni Lenzi <g....@smileupps.com> wrote:
>
>> That looks like you are using a changes filter. A client has to opt into
>> that. what if a client calls changes without the filter?
>
> Request is denied if the changes filter does not receive as query
> parameter(or in path) the same userid which is authenticated (can be done
> comparing req.userCtx.name or anything inside req.userCtx.roles)
That happens in a proxy outside of CouchDB then?
>
> So:
> - changes for non authenticated users is denied
> - changes with incorrect user id are denied
> - to optimize performance, changes request with a since query parameter too
> old, are rejected... and list-view has to be used.
>
>
> 2015-05-05 13:42 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
>
>>
>>> On 05 May 2015, at 13:17, Giovanni Lenzi <g....@smileupps.com> wrote:
>>>
>>>> How do you do per-doc or per-attachment ACL? Those are not core CouchDB
>>> features.
>>>
>>> per-doc:
>>> - read : https://www.smileupps.com/couchapp-tutorial-chatty-read-api
>>
>> That looks like you are using a changes filter. A client has to opt into
>> that. what if a client calls changes without the filter?
>>
>>> - write: https://www.smileupps.com/couchapp-tutorial-chatty-write-api
>>>
>>> per-attachments: a tutorial will come.. however
>>> - write: same method used in
>>> https://www.smileupps.com/couchapp-tutorial-chatty-write-api
>>> - reads: through unguessable ids, which is industry common practice
>>>
>>> all of the above can be seriously enhanced with filtered changes and some
>>> minor improvements to rewriting engine module.
>>>
>>>
>>>
>>> 2015-05-05 13:01 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
>>>
>>>>
>>>>> On 05 May 2015, at 12:54, Giovanni Lenzi <g....@smileupps.com>
>> wrote:
>>>>>
>>>>> I think it's a timing problem.. probably Couchapps were simply not
>> mature
>>>>> enough some years ago.. but nowadays their potential has increased a
>> lot,
>>>>> under every aspect.
>>>>>
>>>>> IMHO they are even one of the best way to implement granular
>> server-side
>>>>> security.
>>>>>
>>>>> - security: server-side read and write ACLS are a reality(
>>>>> https://www.smileupps.com/couchapp-tutorial-chatty)
>>>>> - filtered changes from RCouch will improve security even further
>>>>> - probably, some minor tweaks to the rewriting engine module can
>> easily
>>>>> add ACL at view level, so improving performance on #3
>>>>> - ACL for _attachments is already possible. We have a tutorial
>>>> scheduled
>>>>> on that
>>>>
>>>> How do you do per-doc or per-attachment ACL? Those are not core CouchDB
>>>> features.
>>>>
>>>>
>>>>>
>>>>> - background events are a reality too and they enable Couchapps to
>>>> perform
>>>>> any kind of background REST events:
>>>>> - send email, SMS, payments, scheduled backups.. and so on.. just by
>>>>> interacting with the database
>>>>> - all these jobs can eventually be packed into single-feature-ready
>>>>> couchapps: e.g. "do you need stripe payments on your website?".. just
>>>>> download the stripe couchapp!
>>>>> - the daemon is opensource and implemented in node.js,
>>>>> https://www.smileupps.com/couch-daemon-triggerjob ... but it would be
>>>> great
>>>>> ported to erlang
>>>>>
>>>>> I agree with ermouth a lot can still be done around tooling,
>> performance
>>>>> and scalability (do you think bigcouch can eventually help us on this
>>>>> too?), but I think leaving Couchapps could be really a great error.
>>>>>
>>>>>
>>>>> 2015-05-05 11:49 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
>>>>>
>>>>>>
>>>>>>> On 05 May 2015, at 11:08, Andy Wenk <an...@apache.org> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Jan thanks for raising this important topic!
>>>>>>>
>>>>>>> As I had been around and participated when JChris, Jan and others
>>>> started
>>>>>>> CouchApps and Benoit took over the work, I am a bit sad, that
>> CouchApps
>>>>>>> started to confuse people. And yes it is true, they are limited but
>>>> have
>>>>>>> their place in the history of CouchDB. Far more, it can easily be
>> seen
>>>> as
>>>>>>> the evolutionary basis for Hoodie and that is a good thing imho.
>>>>>>>
>>>>>>> We should give CouchApps a place to live in the CouchDB ecosystem
>> (not
>>>>>>> meant technically). So my proposal is to reactivate couchapp.org and
>>>>>> write
>>>>>>> one page with info about
>>>>>>>
>>>>>>> * what CouchApps are
>>>>>>> * how one can create one (links to doku)
>>>>>>> * what alternatives there are (kanso, hoodie ...)
>>>>>>>
>>>>>>> Furthermore we should include a link on couchdb.org to couchapp.org.
>>>>>>>
>>>>>>> I think it would be wrong to leave people still in the dark even
>> though
>>>>>>> nowadays we think, CouchApps is not the way one should create a
>> WebApp
>>>>>>> based on CouchDB (and I don't think the approaches to create
>> CouchApps
>>>>>> was
>>>>>>> foolish Jan ;-)). It is our responsibility to clarify what CouchApps
>>>> are
>>>>>>> and why one should move forward to sth. better. With clarification
>>>> comes
>>>>>>> clarity
>>>>>>
>>>>>> Thanks Andy! — I’m all for the things you mention, once we figure out
>>>> how
>>>>>> the CouchApps story fits into the larger CouchDB story without
>> confusing
>>>>>> anyone.
>>>>>>
>>>>>> What’s your take on that? :)
>>>>>>
>>>>>> * * *
>>>>>>
>>>>>> Also, I think we shouldn’t be afraid to make CouchApp’s place in
>>>> CouchDB’s
>>>>>> history clear in terms of “This was an idea of its time. Today, we
>> think
>>>>>> differently. RIP CouchApps”.
>>>>>>
>>>>>>
>>>>>> Best
>>>>>> Jan
>>>>>> --
>>>>>>
>>>>>>>
>>>>>>> All the best
>>>>>>>
>>>>>>> Andy
>>>>>>>
>>>>>>>
>>>>>>> On 5 May 2015 at 10:54, Jan Lehnardt <ja...@apache.org> wrote:
>>>>>>>
>>>>>>>> It seems we have a separate discussion going on here, so I forked
>> the
>>>>>>>> thread.
>>>>>>>>
>>>>>>>> I’ve seen these two sides ever since we invented CouchApps:
>>>>>>>>
>>>>>>>> Pro:
>>>>>>>> - CouchApps are amazingly simple
>>>>>>>> - CouchDB as an app server is a great idea, I don’t need to run any
>>>>>> other
>>>>>>>> infrastructure
>>>>>>>> - this is the future of web development
>>>>>>>> - couchapp* is a great tool to manage design docs
>>>>>>>>
>>>>>>>> (*or erica… etc.)
>>>>>>>>
>>>>>>>> Con:
>>>>>>>> - the concept of compiling design docs is confusing
>>>>>>>> - even when they get it, they are confused that they need a third
>>>>>> party
>>>>>>>> tool called `couchapp` to do so, because the documentation talks
>> about
>>>>>>>> building full apps in CouchDB, they have an external app and just
>> want
>>>>>> to
>>>>>>>> use CouchDB as a database, but couchapp is still the tool they need.
>>>>>>>> - the tooling is poor
>>>>>>>> - the tooling is all third-party
>>>>>>>> - they can only cover a very limited use-case
>>>>>>>> - CouchApps are the only way to use CouchDB
>>>>>>>>
>>>>>>>>
>>>>>>>> I see a number of people being passionate about CouchApps and I
>>>> believe
>>>>>>>> their enthusiasm is warranted, CouchApps are a neat idea.
>>>>>>>>
>>>>>>>> But I also see a greater number of people being confused by
>> CouchApps
>>>>>> and
>>>>>>>> in turn by CouchDB.
>>>>>>>>
>>>>>>>> That is not a good situation.
>>>>>>>>
>>>>>>>> Let’s think about how (and if) we can fit the CouchApp story into a
>>>>>>>> coherent CouchDB story.
>>>>>>>>
>>>>>>>> A prerequisite for that is having a coherent CouchDB story, which we
>>>>>> don’t
>>>>>>>> have fully finalised yet, but we have talked about extensively, and
>>>> the
>>>>>>>> consensus is around the “Data where you need it” narrative that
>>>>>> emphasises
>>>>>>>> replication between CouchDB instances and other projects that speak
>>>> the
>>>>>>>> replication protocol (especially PouchDB and TouchDB).
>>>>>>>>
>>>>>>>> How do CouchApps fit into that narrative?
>>>>>>>>
>>>>>>>>
>>>>>>>> * * *
>>>>>>>>
>>>>>>>> (Personal view alert: this is just to give some more background on
>> my
>>>>>> own
>>>>>>>> position, this isn’t meant as a basis for discussion)
>>>>>>>>
>>>>>>>> I’m personally conflicted. When we set out to develop CouchApps, we
>>>>>>>> thought we are inventing a new paradigm for how to build the web,
>> and
>>>>>>>> everybody would follow us, because that would enable a true p2p web.
>>>>>> That
>>>>>>>> didn’t happen and probably was a little foolish of us :D
>>>>>>>>
>>>>>>>> Technically, that would have meant CouchApps had to grow a lot more
>>>> and
>>>>>> I
>>>>>>>> realised quickly that CouchDB is not the right place to grow such a
>>>>>> thing.
>>>>>>>> In addition, there are various fully fledged web frameworks already
>>>> and
>>>>>>>> CouchApps could never really compete in terms of person-power and
>>>>>> attention.
>>>>>>>>
>>>>>>>> That all led me to re-evaluate the whole value proposition, when
>>>> things
>>>>>>>> like PouchDB came up and the browser became a decent application
>>>>>>>> development platform. That whole thinking led to the creation of
>>>> Hoodie
>>>>>> (
>>>>>>>> http://hood.ie), which started out with the code name CANG (Couch
>>>> Apps
>>>>>>>> Next Generation), where we liked some of the core ideas of
>> CouchApps,
>>>>>> but
>>>>>>>> wanted to address the limitations that would stifle their adoption.
>>>>>> Hoodie
>>>>>>>> embraces browser-to-server sync to allow fully offline apps, it
>> allows
>>>>>>>> all-javascript-all-json development on the front- and back-end. It
>>>> uses
>>>>>> the
>>>>>>>> database-per-user and the _changes-feed-as-async-worker paradigms
>> and
>>>>>> it is
>>>>>>>> all wrapped into a package that is *really* easy to understand and
>> get
>>>>>>>> started with. Hoodie, unlike CouchApps, does have a fighting chance
>> of
>>>>>>>> making CouchDB’s unique features (replication, _changes) available
>>>> for a
>>>>>>>> larger population and I’m infinitely excited about that.
>>>>>>>>
>>>>>>>> * * *
>>>>>>>>
>>>>>>>> All that doesn’t mean, however, that CouchApps don’t have their
>> place,
>>>>>> but
>>>>>>>> again, I’m not sure where that place is and the place it currently
>> has
>>>>>>>> seems to negatively affect CouchDB, so I’d like for this list to
>> think
>>>>>> and
>>>>>>>> talk about all that for a bit.
>>>>>>>>
>>>>>>>> How can we make it that CouchApps strengthen CouchDB and not weaken
>> it
>>>>>> by
>>>>>>>> adding confusion?
>>>>>>>>
>>>>>>>> How do CouchApps fit into the CouchDB story?
>>>>>>>>
>>>>>>>>
>>>>>>>> Best
>>>>>>>> Jan
>>>>>>>> --
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 05 May 2015, at 08:45, ermouth <er...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> CouchDB-killing answers
>>>>>>>>>
>>>>>>>>> Well... When someone says couchapps is silver bullet – I say ‘No’
>>>> and I
>>>>>>>> can
>>>>>>>>> prove it. Couchapps have a lot, A LOT of problems, and some of them
>>>> can
>>>>>>>> not
>>>>>>>>> be solved inside CouchDB. For example, try to implement ACL for
>>>>>>>> attachments
>>>>>>>>> or try to scale couchapp. You just can‘t do it in reasonable way.
>>>>>>>>>
>>>>>>>>> I know several engineers who tried out couchapps – and left CouchDB
>>>>>>>>> forever. Not because CouchDB itself, but because couchapps.
>> O‘Reilly
>>>>>> said
>>>>>>>>> it‘s a silver bullet, others said – and what we have? Sloppy and
>>>>>>>>> hard-to-debug architecture, that does not scale, has no tooling
>> and a
>>>>>> lot
>>>>>>>>> of security issues.
>>>>>>>>>
>>>>>>>>> You gonna solve architecture problems with positive posts?
>>>>>>>>>
>>>>>>>>> What I want to say – there is no need to lie and say couchapps are
>>>>>> great.
>>>>>>>>> Because they are not.
>>>>>>>>>
>>>>>>>>>> would you like to write down some of your positive:-))
>> experiences?
>>>>>>>>>
>>>>>>>>> http://ermouth.livejournal.com/tag/couchdb – sorry, Russian
>>>> language.
>>>>>>>>>
>>>>>>>>> ermouth
>>>>>>>>
>>>>>>>> --
>>>>>>>> Professional Support for Apache CouchDB:
>>>>>>>> http://www.neighbourhood.ie/couchdb-support/
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Andy Wenk
>>>>>>> Hamburg - Germany
>>>>>>> RockIt!
>>>>>>>
>>>>>>> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588
>>>>>>>
>>>>>>> https://people.apache.org/keys/committer/andywenk.asc
>>>>>>
>>>>>> --
>>>>>> Professional Support for Apache CouchDB:
>>>>>> http://www.neighbourhood.ie/couchdb-support/
>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Professional Support for Apache CouchDB:
>>>> http://www.neighbourhood.ie/couchdb-support/
>>>>
>>>>
>>
>> --
>> Professional Support for Apache CouchDB:
>> http://www.neighbourhood.ie/couchdb-support/
>>
>>
--
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/
Re: SmileUpps Features (Was: How do CouchApps fit into the CouchDB
story? (Was: CouchDB Articles, Pills and Tutorials Ideas))
Posted by Giovanni Lenzi <g....@smileupps.com>.
> That looks like you are using a changes filter. A client has to opt into
that. what if a client calls changes without the filter?
Request is denied if the changes filter does not receive as query
parameter(or in path) the same userid which is authenticated (can be done
comparing req.userCtx.name or anything inside req.userCtx.roles)
So:
- changes for non authenticated users is denied
- changes with incorrect user id are denied
- to optimize performance, changes request with a since query parameter too
old, are rejected... and list-view has to be used.
2015-05-05 13:42 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
>
> > On 05 May 2015, at 13:17, Giovanni Lenzi <g....@smileupps.com> wrote:
> >
> >> How do you do per-doc or per-attachment ACL? Those are not core CouchDB
> > features.
> >
> > per-doc:
> > - read : https://www.smileupps.com/couchapp-tutorial-chatty-read-api
>
> That looks like you are using a changes filter. A client has to opt into
> that. what if a client calls changes without the filter?
>
> > - write: https://www.smileupps.com/couchapp-tutorial-chatty-write-api
> >
> > per-attachments: a tutorial will come.. however
> > - write: same method used in
> > https://www.smileupps.com/couchapp-tutorial-chatty-write-api
> > - reads: through unguessable ids, which is industry common practice
> >
> > all of the above can be seriously enhanced with filtered changes and some
> > minor improvements to rewriting engine module.
> >
> >
> >
> > 2015-05-05 13:01 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
> >
> >>
> >>> On 05 May 2015, at 12:54, Giovanni Lenzi <g....@smileupps.com>
> wrote:
> >>>
> >>> I think it's a timing problem.. probably Couchapps were simply not
> mature
> >>> enough some years ago.. but nowadays their potential has increased a
> lot,
> >>> under every aspect.
> >>>
> >>> IMHO they are even one of the best way to implement granular
> server-side
> >>> security.
> >>>
> >>> - security: server-side read and write ACLS are a reality(
> >>> https://www.smileupps.com/couchapp-tutorial-chatty)
> >>> - filtered changes from RCouch will improve security even further
> >>> - probably, some minor tweaks to the rewriting engine module can
> easily
> >>> add ACL at view level, so improving performance on #3
> >>> - ACL for _attachments is already possible. We have a tutorial
> >> scheduled
> >>> on that
> >>
> >> How do you do per-doc or per-attachment ACL? Those are not core CouchDB
> >> features.
> >>
> >>
> >>>
> >>> - background events are a reality too and they enable Couchapps to
> >> perform
> >>> any kind of background REST events:
> >>> - send email, SMS, payments, scheduled backups.. and so on.. just by
> >>> interacting with the database
> >>> - all these jobs can eventually be packed into single-feature-ready
> >>> couchapps: e.g. "do you need stripe payments on your website?".. just
> >>> download the stripe couchapp!
> >>> - the daemon is opensource and implemented in node.js,
> >>> https://www.smileupps.com/couch-daemon-triggerjob ... but it would be
> >> great
> >>> ported to erlang
> >>>
> >>> I agree with ermouth a lot can still be done around tooling,
> performance
> >>> and scalability (do you think bigcouch can eventually help us on this
> >>> too?), but I think leaving Couchapps could be really a great error.
> >>>
> >>>
> >>> 2015-05-05 11:49 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
> >>>
> >>>>
> >>>>> On 05 May 2015, at 11:08, Andy Wenk <an...@apache.org> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> Jan thanks for raising this important topic!
> >>>>>
> >>>>> As I had been around and participated when JChris, Jan and others
> >> started
> >>>>> CouchApps and Benoit took over the work, I am a bit sad, that
> CouchApps
> >>>>> started to confuse people. And yes it is true, they are limited but
> >> have
> >>>>> their place in the history of CouchDB. Far more, it can easily be
> seen
> >> as
> >>>>> the evolutionary basis for Hoodie and that is a good thing imho.
> >>>>>
> >>>>> We should give CouchApps a place to live in the CouchDB ecosystem
> (not
> >>>>> meant technically). So my proposal is to reactivate couchapp.org and
> >>>> write
> >>>>> one page with info about
> >>>>>
> >>>>> * what CouchApps are
> >>>>> * how one can create one (links to doku)
> >>>>> * what alternatives there are (kanso, hoodie ...)
> >>>>>
> >>>>> Furthermore we should include a link on couchdb.org to couchapp.org.
> >>>>>
> >>>>> I think it would be wrong to leave people still in the dark even
> though
> >>>>> nowadays we think, CouchApps is not the way one should create a
> WebApp
> >>>>> based on CouchDB (and I don't think the approaches to create
> CouchApps
> >>>> was
> >>>>> foolish Jan ;-)). It is our responsibility to clarify what CouchApps
> >> are
> >>>>> and why one should move forward to sth. better. With clarification
> >> comes
> >>>>> clarity
> >>>>
> >>>> Thanks Andy! — I’m all for the things you mention, once we figure out
> >> how
> >>>> the CouchApps story fits into the larger CouchDB story without
> confusing
> >>>> anyone.
> >>>>
> >>>> What’s your take on that? :)
> >>>>
> >>>> * * *
> >>>>
> >>>> Also, I think we shouldn’t be afraid to make CouchApp’s place in
> >> CouchDB’s
> >>>> history clear in terms of “This was an idea of its time. Today, we
> think
> >>>> differently. RIP CouchApps”.
> >>>>
> >>>>
> >>>> Best
> >>>> Jan
> >>>> --
> >>>>
> >>>>>
> >>>>> All the best
> >>>>>
> >>>>> Andy
> >>>>>
> >>>>>
> >>>>> On 5 May 2015 at 10:54, Jan Lehnardt <ja...@apache.org> wrote:
> >>>>>
> >>>>>> It seems we have a separate discussion going on here, so I forked
> the
> >>>>>> thread.
> >>>>>>
> >>>>>> I’ve seen these two sides ever since we invented CouchApps:
> >>>>>>
> >>>>>> Pro:
> >>>>>> - CouchApps are amazingly simple
> >>>>>> - CouchDB as an app server is a great idea, I don’t need to run any
> >>>> other
> >>>>>> infrastructure
> >>>>>> - this is the future of web development
> >>>>>> - couchapp* is a great tool to manage design docs
> >>>>>>
> >>>>>> (*or erica… etc.)
> >>>>>>
> >>>>>> Con:
> >>>>>> - the concept of compiling design docs is confusing
> >>>>>> - even when they get it, they are confused that they need a third
> >>>> party
> >>>>>> tool called `couchapp` to do so, because the documentation talks
> about
> >>>>>> building full apps in CouchDB, they have an external app and just
> want
> >>>> to
> >>>>>> use CouchDB as a database, but couchapp is still the tool they need.
> >>>>>> - the tooling is poor
> >>>>>> - the tooling is all third-party
> >>>>>> - they can only cover a very limited use-case
> >>>>>> - CouchApps are the only way to use CouchDB
> >>>>>>
> >>>>>>
> >>>>>> I see a number of people being passionate about CouchApps and I
> >> believe
> >>>>>> their enthusiasm is warranted, CouchApps are a neat idea.
> >>>>>>
> >>>>>> But I also see a greater number of people being confused by
> CouchApps
> >>>> and
> >>>>>> in turn by CouchDB.
> >>>>>>
> >>>>>> That is not a good situation.
> >>>>>>
> >>>>>> Let’s think about how (and if) we can fit the CouchApp story into a
> >>>>>> coherent CouchDB story.
> >>>>>>
> >>>>>> A prerequisite for that is having a coherent CouchDB story, which we
> >>>> don’t
> >>>>>> have fully finalised yet, but we have talked about extensively, and
> >> the
> >>>>>> consensus is around the “Data where you need it” narrative that
> >>>> emphasises
> >>>>>> replication between CouchDB instances and other projects that speak
> >> the
> >>>>>> replication protocol (especially PouchDB and TouchDB).
> >>>>>>
> >>>>>> How do CouchApps fit into that narrative?
> >>>>>>
> >>>>>>
> >>>>>> * * *
> >>>>>>
> >>>>>> (Personal view alert: this is just to give some more background on
> my
> >>>> own
> >>>>>> position, this isn’t meant as a basis for discussion)
> >>>>>>
> >>>>>> I’m personally conflicted. When we set out to develop CouchApps, we
> >>>>>> thought we are inventing a new paradigm for how to build the web,
> and
> >>>>>> everybody would follow us, because that would enable a true p2p web.
> >>>> That
> >>>>>> didn’t happen and probably was a little foolish of us :D
> >>>>>>
> >>>>>> Technically, that would have meant CouchApps had to grow a lot more
> >> and
> >>>> I
> >>>>>> realised quickly that CouchDB is not the right place to grow such a
> >>>> thing.
> >>>>>> In addition, there are various fully fledged web frameworks already
> >> and
> >>>>>> CouchApps could never really compete in terms of person-power and
> >>>> attention.
> >>>>>>
> >>>>>> That all led me to re-evaluate the whole value proposition, when
> >> things
> >>>>>> like PouchDB came up and the browser became a decent application
> >>>>>> development platform. That whole thinking led to the creation of
> >> Hoodie
> >>>> (
> >>>>>> http://hood.ie), which started out with the code name CANG (Couch
> >> Apps
> >>>>>> Next Generation), where we liked some of the core ideas of
> CouchApps,
> >>>> but
> >>>>>> wanted to address the limitations that would stifle their adoption.
> >>>> Hoodie
> >>>>>> embraces browser-to-server sync to allow fully offline apps, it
> allows
> >>>>>> all-javascript-all-json development on the front- and back-end. It
> >> uses
> >>>> the
> >>>>>> database-per-user and the _changes-feed-as-async-worker paradigms
> and
> >>>> it is
> >>>>>> all wrapped into a package that is *really* easy to understand and
> get
> >>>>>> started with. Hoodie, unlike CouchApps, does have a fighting chance
> of
> >>>>>> making CouchDB’s unique features (replication, _changes) available
> >> for a
> >>>>>> larger population and I’m infinitely excited about that.
> >>>>>>
> >>>>>> * * *
> >>>>>>
> >>>>>> All that doesn’t mean, however, that CouchApps don’t have their
> place,
> >>>> but
> >>>>>> again, I’m not sure where that place is and the place it currently
> has
> >>>>>> seems to negatively affect CouchDB, so I’d like for this list to
> think
> >>>> and
> >>>>>> talk about all that for a bit.
> >>>>>>
> >>>>>> How can we make it that CouchApps strengthen CouchDB and not weaken
> it
> >>>> by
> >>>>>> adding confusion?
> >>>>>>
> >>>>>> How do CouchApps fit into the CouchDB story?
> >>>>>>
> >>>>>>
> >>>>>> Best
> >>>>>> Jan
> >>>>>> --
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> On 05 May 2015, at 08:45, ermouth <er...@gmail.com> wrote:
> >>>>>>>
> >>>>>>>> CouchDB-killing answers
> >>>>>>>
> >>>>>>> Well... When someone says couchapps is silver bullet – I say ‘No’
> >> and I
> >>>>>> can
> >>>>>>> prove it. Couchapps have a lot, A LOT of problems, and some of them
> >> can
> >>>>>> not
> >>>>>>> be solved inside CouchDB. For example, try to implement ACL for
> >>>>>> attachments
> >>>>>>> or try to scale couchapp. You just can‘t do it in reasonable way.
> >>>>>>>
> >>>>>>> I know several engineers who tried out couchapps – and left CouchDB
> >>>>>>> forever. Not because CouchDB itself, but because couchapps.
> O‘Reilly
> >>>> said
> >>>>>>> it‘s a silver bullet, others said – and what we have? Sloppy and
> >>>>>>> hard-to-debug architecture, that does not scale, has no tooling
> and a
> >>>> lot
> >>>>>>> of security issues.
> >>>>>>>
> >>>>>>> You gonna solve architecture problems with positive posts?
> >>>>>>>
> >>>>>>> What I want to say – there is no need to lie and say couchapps are
> >>>> great.
> >>>>>>> Because they are not.
> >>>>>>>
> >>>>>>>> would you like to write down some of your positive:-))
> experiences?
> >>>>>>>
> >>>>>>> http://ermouth.livejournal.com/tag/couchdb – sorry, Russian
> >> language.
> >>>>>>>
> >>>>>>> ermouth
> >>>>>>
> >>>>>> --
> >>>>>> Professional Support for Apache CouchDB:
> >>>>>> http://www.neighbourhood.ie/couchdb-support/
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Andy Wenk
> >>>>> Hamburg - Germany
> >>>>> RockIt!
> >>>>>
> >>>>> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588
> >>>>>
> >>>>> https://people.apache.org/keys/committer/andywenk.asc
> >>>>
> >>>> --
> >>>> Professional Support for Apache CouchDB:
> >>>> http://www.neighbourhood.ie/couchdb-support/
> >>>>
> >>>>
> >>
> >> --
> >> Professional Support for Apache CouchDB:
> >> http://www.neighbourhood.ie/couchdb-support/
> >>
> >>
>
> --
> Professional Support for Apache CouchDB:
> http://www.neighbourhood.ie/couchdb-support/
>
>