Jeff, I just started probing at the externals API. Didn't know what it did exactly and it looks cool. What are the advantages/disadvantages of using that vs using something node as a proxy to couch?
On Thu, Mar 7, 2013 at 12:54 PM, Tim Anderson <timatb...@gmail.com> wrote: > Anybody using couchdb as data layer with Grails? > > > On Thu, Mar 7, 2013 at 11:38 AM, Jeff Charette <ioma...@yahoo.com> wrote: > > > I use pure couchapps backed by node processes for transactions. > > I use kanso to manage my couchapps. May switch to just grunt and manage > > packages on npm. > > > > For security everything goes through rewrites then design doc shows, > > lists, updates. This messes up my ability to upload attachments since I > > need secure_rewrites. I am currently working through the database per > user > > setup as well. > > > > Also would love to hear how people are using externals. I am passing > > transactions request directly to externals then to node, but have only > been > > able to do GET request. Finally, I set the state of a document on couch > > when the node process is complete. I do have a question of how people > are > > authenticating back to couchdb. Is the AuthSession cookie enough? > > > > Jeff Charette | Principal > > We Are Charette > > web / identity / packaging > > > > m 415.298.2707 > > w wearecharette.com > > e jeff...@wearecharette.com > > > > On Mar 7, 2013, at 10:57 AM, svilen <a...@svilendobrev.com> wrote: > > > > > probably, for going this way, one might use non-blocking > > > long_poll webframework like python/Tornado to wrap couchdb > > > replication/changes feed too. Thus something like > > > http:(someuserauth)//appserver/mychannel can route to couchdb's > > > changes for that database - or even aggregation - for that user even > > > if notion of user is not at all couchdb's one. > > > haven't tried it though. > > > > > > On Fri, 8 Mar 2013 00:47:38 +0900 > > > TAE JIN KIM <snoweb...@hotmail.com> wrote: > > > > > >> Daniel, > > >> > > >> So basically, what you r saying is that you put application layer in > > >> front of couch, so user no direct access to the couch.. Right?..I > > >> think you did pretty much similar thing #2 in my original post... > > >> BTW, just out of curiosity, by doing this, any performance > > >> degradation / or any trouble stuff you may have to face with > > >> something you might had not expected at all ?... > > >> > > >> Thanks, > > >> > > >>> From: gonva...@gonvaled.com > > >>> Date: Thu, 7 Mar 2013 16:37:36 +0100 > > >>> Subject: Re: Curiosity how you use CouchDB in your web env. > > >>> To: user@couchdb.apache.org > > >>> > > >>> Well, if things were always so easy! > > >>> > > >>> We have this scenario: our webapp has to server data to different > > >>> organizations (hopefully thousands, if our product sells well). > > >>> That means we can not partition data in different databases: it > > >>> would be a maintenance nightmare. can somebody tell me how to: > > >>> > > >>> - upgrade the design docs in 1000 databases without going crazy? > > >>> - How to backup them? > > >>> - ... > > >>> > > >>> I mean, the more databases you have, the more complicated > > >>> maintenance becomes. Maybe that can be automated, but it is not > > >>> easy out of the box. > > >>> > > >>> Besides, I do not want to implement the following: > > >>> > > >>> - new organization signs-up > > >>> - we create a new database for it > > >>> - we upload the design documens > > >>> - we trigger those documents > > >>> > > >>> I mean, it is probably doable, but I am not walking that path right > > >>> now. So, the only way that I know of in which we can partition the > > >>> data is by having an application server in front of couch: a single > > >>> database for all customers, with access control implemented via > > >>> view filtering with the org_id as key. The user has no direct > > >>> access to couch. > > >>> > > >>> On Wed, Mar 6, 2013 at 7:42 PM, Robert Newson <rnew...@apache.org> > > >>> wrote: > > >>> > > >>>> Don't grant users access to databases you don't want them to > > >>>> read. :) > > >>>> > > >>>> > > http://wiki.apache.org/couchdb/Security_Features_Overview#Authorization > > >>>> > > >>>> B. > > >>>> > > >>>> On 6 March 2013 12:33, Mark Hahn <m...@hahnca.com> wrote: > > >>>>> Anyone logged in can read any document in the DB. I have to > > >>>>> check each user and what they are trying to do to block illegal > > >>>>> actions. > > >>>>> > > >>>>> > > >>>>> On Wed, Mar 6, 2013 at 9:51 AM, Robert Newson > > >>>>> <rnew...@apache.org> > > >>>> wrote: > > >>>>> > > >>>>>> "How does everyone solve the security issue?" > > >>>>>> > > >>>>>> What security problem? Only administrators can modify design > > >>>>>> documents. > > >>>>>> > > >>>>>> B. > > >>>>>> > > >>>>>> On 6 March 2013 11:38, Aurélien Bénel <aurelien.be...@utt.fr> > > >>>>>> wrote: > > >>>>>>> Hi, > > >>>>>>> > > >>>>>>>> just out of curiosity, would like to hear how CouchDB is > > >>>>>>>> being used > > >>>> in > > >>>>>> your web environment.... > > >>>>>>> > > >>>>>>> We have two main setups: > > >>>>>>> - CouchApps, > > >>>>>>> - REST APIs used by heavy clients (Java or Firefox > > >>>>>>> extensions) and > > >>>>>> attached Web applications. > > >>>>>>> > > >>>>>>>> How does everyone solve the security issue? > > >>>>>>> > > >>>>>>> We always use CouchDB behind a reverse proxy to add LDAP > > >>>> authentication > > >>>>>> and authorization when needed. > > >>>>>>> > > >>>>>>> > > >>>>>>> Regards, > > >>>>>>> > > >>>>>>> Aurélien > > >>>>>> > > >>>> > > >> > > > > >
