You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by TAE JIN KIM <sn...@hotmail.com> on 2013/03/06 17:21:36 UTC
Curiosity how you use CouchDB in your web env.
There are couple of ways that CouchDB can be used in web development.
You could deploy your html as attachment in _design in your couch db..so actually couchdb could serve your html....
You could create a kind of proxy middle layer so that this can communicate between your presentation layer and your CouchDB due to cross-domain issue of Ajax..
There might be some different way as well....
There is no obvious right answer approach here I guess, but just out of curiosity, would like to hear
how CouchDB is being used in your web environment....
if you had all of experience as far as deployment is concerned, that would be great if you could share for each pros/cons as well...
Thanks in advance.
Re: Curiosity how you use CouchDB in your web env.
Posted by "Kevin R. Coombes" <ke...@gmail.com>.
I mostly prefer to use the "couchapp" approach where the html and
javascript for the UI are stored as attachments to the design document,
with jQuery handling the interactions between the browser and couch.
On 3/6/2013 10:45 AM, Mark Hahn wrote:
> I have a node app that does all html serving and my app talks directly to
> couch via 127.0.0.1. I think this is the most common setup.
>
>
> On Wed, Mar 6, 2013 at 8:21 AM, TAE JIN KIM<sn...@hotmail.com> wrote:
>
>> There are couple of ways that CouchDB can be used in web development.
>>
>> You could deploy your html as attachment in _design in your couch db..so
>> actually couchdb could serve your html....
>> You could create a kind of proxy middle layer so that this can communicate
>> between your presentation layer and your CouchDB due to cross-domain issue
>> of Ajax..
>> There might be some different way as well....
>>
>> There is no obvious right answer approach here I guess, but just out of
>> curiosity, would like to hear
>> how CouchDB is being used in your web environment....
>> if you had all of experience as far as deployment is concerned, that would
>> be great if you could share for each pros/cons as well...
>>
>> Thanks in advance.
>>
>>
>>
>>
Re: Curiosity how you use CouchDB in your web env.
Posted by Travis Paul <Tr...@visPaul.me>.
I use CouchApps, they are my favorite feature of CouchDB and the sole
reason I don't use CouchBase. I always have CouchDB behind Nginx as a
reverse proxy so that I can Gzip content and use port 80 and 443 without
running CouchDB as root. If CouchDB could Gzip content then I could get rid
of Nginx completely and use Iptables for port 80 and 443 but I don't really
mind it so much. I could always potentially use Nginx as a load balancer if
I ever needed. I also use NodeJs for sending emails and for Cronjobs
(Compacting the DB, removing expired documents, etc).
On Wed, Mar 6, 2013 at 12:19 PM, Mark Hahn <ma...@hahnca.com> wrote:
> > I'd personally *hope* that most people are serving CouchDB directly
>
> How does everyone solve the security issue? When I initially looked into
> using couchdb from the browser I ran into a brick wall because I could
> figure out no way to keep rogue JS code from trashing the DB. I do access
> much of the http interface from the browser but I have to go through the
> app to validate all requests.
>
>
>
> On Wed, Mar 6, 2013 at 8:59 AM, Robert Newson <rn...@apache.org> wrote:
>
> > "I think this is the most common setup." -- I'm not so sure, but I'd
> > love to get some numbers.
> >
> > I'd personally *hope* that most people are serving CouchDB directly
> > with the possible exception of a generic load balancer like HAProxy.
> >
> > B.
> >
> > On 6 March 2013 10:54, Dan Santner <da...@me.com> wrote:
> > > I use couchdb as a restful doc persistence. I don't use CouchApp.
> > > On Mar 6, 2013, at 10:45 AM, Mark Hahn <ma...@hahnca.com> wrote:
> > >
> > >> I have a node app that does all html serving and my app talks directly
> > to
> > >> couch via 127.0.0.1. I think this is the most common setup.
> > >>
> > >>
> > >> On Wed, Mar 6, 2013 at 8:21 AM, TAE JIN KIM <sn...@hotmail.com>
> > wrote:
> > >>
> > >>> There are couple of ways that CouchDB can be used in web development.
> > >>>
> > >>> You could deploy your html as attachment in _design in your couch
> > db..so
> > >>> actually couchdb could serve your html....
> > >>> You could create a kind of proxy middle layer so that this can
> > communicate
> > >>> between your presentation layer and your CouchDB due to cross-domain
> > issue
> > >>> of Ajax..
> > >>> There might be some different way as well....
> > >>>
> > >>> There is no obvious right answer approach here I guess, but just out
> of
> > >>> curiosity, would like to hear
> > >>> how CouchDB is being used in your web environment....
> > >>> if you had all of experience as far as deployment is concerned, that
> > would
> > >>> be great if you could share for each pros/cons as well...
> > >>>
> > >>> Thanks in advance.
> > >>>
> > >>>
> > >>>
> > >>>
> > >
> >
>
Re: Curiosity how you use CouchDB in your web env.
Posted by Lance Carlson <la...@gmail.com>.
I've been deploying some robust apps as couchapps recently and I've
had mixed results. Overall I really like the new setup but I think
there is room for improvement. I stick my app behind a node js proxy
(and also use it like a worker). To handle security, I have two
databases. One that handles registration and and any data I don't mind
being public and I have a separate database that stores all of the
private data and which is only accessible by the admin user. I'm
paranoid so I created an admin user and set require valid user to
true. My proxy then makes every "public" request to my public couchapp
authenticated as the admin (until the user logs in, in which case they
are then authenticated as themselves). For any private data that
pertains to them and only them, they have to get access to that data
only after that are authenticated and then the admin user grabs that
data for them from the private database. I'm still debating whether
this is overkill but I really like the idea of pushing the logic into
the database as much as possible.
Sent from my iPhone
On Mar 6, 2013, at 3:05 PM, Sean Copenhaver <se...@gmail.com> wrote:
> I've made a site that was only a couchapp and enjoyed the experience quite
> a bit. I've also used it for internal tooling to store data and to host
> mini couchapps for search or utility pages.
>
> In all cases though security of data (at least I didn't care who could read
> the data) was not a requirement and I've greatly enjoyed my experiences. I
> would love to play around with gardener along with an OS daemon to try a
> tightly coupled nodejs + couchdb setup. Would also love to see CouchDB
> hosts to offer such things as well.
>
>
>
> On Wed, Mar 6, 2013 at 2:51 PM, Dan Santner <da...@me.com> wrote:
>
>> I think it's brilliant as just a database and no more. So that's how I
>> use it. I have a similar setup to your #2. Perhaps that just because I
>> feel most comfortable with that type of setup. This way I don't burden
>> couch with anything security related. It just eats and serves docs. My
>> app tier handles the access control and other tasks like email or any other
>> services over the net that I need to use.
>>
>>
>> On Mar 6, 2013, at 1:27 PM, Wendall Cada <we...@83864.com> wrote:
>>
>>> We use couchdb in two configurations.
>>>
>>> 1. As a couchapp serving content for basic consumption. (For a url
>> shortener service)
>>> 2. As a database on localhost behind pylons or pyramid.
>>>
>>> To address the security question. We've been using couchdb for long
>> enough that it didn't have any security when we started using it in
>> production (0.8). Up until recently _users was a somewhat insecure feature.
>> It's only been with the release of 1.2.0 that _users is handled securely.
>>>
>>> For our needs, couchdb still does not have robust enough acls for any of
>> our applications, so for now, it needs to run behind our app servers. I see
>> changes for this on the roadmap, but until this actually happens, couchdb
>> will happily sit on localhost serving docs.
>>>
>>> I'm not sure why it isn't understood that based on it's history, CouchDB
>> has mostly been used as a database. I know people want it to be an app
>> server, but, in my opinion, that's the weakest part of the entire system.
>>>
>>> Wendall
>>>
>>> On 03/06/2013 09:51 AM, Robert Newson 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 <au...@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
>
>
> --
> “The limits of language are the limits of one's world. “ - Ludwig von
> Wittgenstein
>
> "Water is fluid, soft and yielding. But water will wear away rock, which is
> rigid and cannot yield. As a rule, whatever is fluid, soft and yielding
> will overcome whatever is rigid and hard. This is another paradox: what is
> soft is strong." - Lao-Tzu
Re: Curiosity how you use CouchDB in your web env.
Posted by Lance Carlson <la...@gmail.com>.
Dale,
I'm A bit confused. You gave up on couchapps but still serve requests
directly to couch?
Sent from my iPhone
On Mar 7, 2013, at 10:17 AM, David Rose <do...@gmail.com> wrote:
> Dale! Get in touch when you get here. 1 512 769 1392.
>
>
> On Wed, Mar 6, 2013 at 4:17 PM, Dale Harvey <da...@arandomurl.com> wrote:
>
>> After a long time trying to bend CouchApps into what I wanted it do it, I
>> have eventually given up and now pretty much all my applications are
>> webapps served from a plain webserver and talk to either couch directly or
>> via some application logic written node
>>
>> Also I will be at SXSW picking up my badge next week, so see you there :)
>>
>> On 6 March 2013 22:59, David Rose <do...@gmail.com> wrote:
>>
>>> My most recent app, which we're using at SXSW for badge pickup, is a pure
>>> CouchApp. If you're at SXSW, try and find me and I'll show it to you. Or,
>>> look over the counter when you come pick up your badge.
>>>
>>> -David Rose
>>> SXSW
>>>
>>>
>>> On Wed, Mar 6, 2013 at 3:37 PM, svilen <az...@svilendobrev.com> wrote:
>>>
>>>> i'm trying to use couchdb as user-facing storage, message
>>>> transport, as well as authentication. All changes=signals are handled
>>>> via secondary pub-sub-dispatcher in python (somewhat like syncpoint).
>>>> Clients replicate and talk to their own copies mostly.
>>>> Still no escape from extra webapp/python layer - to click on the link
>>>> in the confirmation email, accounts and all that webapp. Mostly
>>>> achieving same fuctionality being triggered both via http as well
>>>> as document-changes. i'm staying away from js although i do generate
>> the
>>>> js, java, objC, .. for models or view map/reduce funcs. Haven't put
>>>> any thought on further scaling or wrapping. or validation of
>>>> FiniteStateMachines that the app has turned into. or.. Maintenance.
>>>>
>>>> Though i'm quite stretched... as authentication is not
>>>> well exampled, does not easy fit the
>>>> multiple-changeable-keysets-per-user reality, and only plain
>>>> usr/psw is 100% supported in mobile touchdb replications.
>>>>
>>>> but ce-la-vie. will invent something..
>>>>
>>>> svil
>>>> www.svilendobrev.com/rabota/
>>>>
>>>> On Wed, 6 Mar 2013 15:20:29 -0500
>>>> Simon de boer <sd...@ingamer.com> wrote:
>>>>
>>>>> It would be great to take out the application layer, but the need for
>>>>> more Authorization controls in a relatively straight forward manner
>>>>> would be key to having this work.
>>>>>
>>>>> There are many use cases where data for one user should be completely
>>>>> impossible to access by another user. And the more complex case of
>>>>> some data being conditionally private, ex. my friends can see my
>> email
>>>>> address, but it is private for all other users.
>>>>>
>>>>> Not only do these sort of inter-connections require more
>> authorization
>>>>> capability, but might require extreme engineering in order to wedge
>>>>> them into the CouchDB paradigm.
>>>>>
>>>>> The other option is that some requests go direct to CouchDB, as in
>> the
>>>>> public items, but other items go through the application. Which is
>>>>> entirely viable, but you would be have be working at such a scale to
>>>>> make the overhead of maintaining this setup worthwhile.
>>>>>
>>>>> FWIW: I use a heavy Javascript client, Rails (Apache + Passenger),
>>>>> MemCache, with data migrating on a feature by feature basis from
>> MySQL
>>>>> and to CouchDB. The eventual plan is to move to a much thinner
>>>>> Application Server with data backed by Redis and CouchDB.
>>>>>
>>>>> On Wed, Mar 6, 2013 at 3:05 PM, Sean Copenhaver
>>>>> <se...@gmail.com> wrote:
>>>>>> I've made a site that was only a couchapp and enjoyed the
>>>>>> experience quite a bit. I've also used it for internal tooling to
>>>>>> store data and to host mini couchapps for search or utility pages.
>>>>>>
>>>>>> In all cases though security of data (at least I didn't care who
>>>>>> could read the data) was not a requirement and I've greatly
>>>>>> enjoyed my experiences. I would love to play around with gardener
>>>>>> along with an OS daemon to try a tightly coupled nodejs + couchdb
>>>>>> setup. Would also love to see CouchDB hosts to offer such things as
>>>>>> well.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 6, 2013 at 2:51 PM, Dan Santner <da...@me.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I think it's brilliant as just a database and no more. So that's
>>>>>>> how I use it. I have a similar setup to your #2. Perhaps that
>>>>>>> just because I feel most comfortable with that type of setup.
>>>>>>> This way I don't burden couch with anything security related. It
>>>>>>> just eats and serves docs. My app tier handles the access control
>>>>>>> and other tasks like email or any other services over the net that
>>>>>>> I need to use.
>>>>>>>
>>>>>>>
>>>>>>> On Mar 6, 2013, at 1:27 PM, Wendall Cada <we...@83864.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> We use couchdb in two configurations.
>>>>>>>>
>>>>>>>> 1. As a couchapp serving content for basic consumption. (For a
>>>>>>>> url
>>>>>>> shortener service)
>>>>>>>> 2. As a database on localhost behind pylons or pyramid.
>>>>>>>>
>>>>>>>> To address the security question. We've been using couchdb for
>>>>>>>> long
>>>>>>> enough that it didn't have any security when we started using it
>> in
>>>>>>> production (0.8). Up until recently _users was a somewhat insecure
>>>>>>> feature. It's only been with the release of 1.2.0 that _users is
>>>>>>> handled securely.
>>>>>>>>
>>>>>>>> For our needs, couchdb still does not have robust enough acls
>>>>>>>> for any of
>>>>>>> our applications, so for now, it needs to run behind our app
>>>>>>> servers. I see changes for this on the roadmap, but until this
>>>>>>> actually happens, couchdb will happily sit on localhost serving
>>>>>>> docs.
>>>>>>>>
>>>>>>>> I'm not sure why it isn't understood that based on it's history,
>>>>>>>> CouchDB
>>>>>>> has mostly been used as a database. I know people want it to be an
>>>>>>> app server, but, in my opinion, that's the weakest part of the
>>>>>>> entire system.
>>>>>>>>
>>>>>>>> Wendall
>>>>>>>>
>>>>>>>> On 03/06/2013 09:51 AM, Robert Newson 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 <au...@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
>>>>>>
>>>>>>
>>>>>> --
>>>>>> “The limits of language are the limits of one's world. “ - Ludwig
>>>>>> von Wittgenstein
>>>>>>
>>>>>> "Water is fluid, soft and yielding. But water will wear away rock,
>>>>>> which is rigid and cannot yield. As a rule, whatever is fluid, soft
>>>>>> and yielding will overcome whatever is rigid and hard. This is
>>>>>> another paradox: what is soft is strong." - Lao-Tzu
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Become the head coach with InGamer Sports!
>>>>> http://www.InGamer.com/
>>>>>
>>>>> Simon de Boer
>>>>> 519-400-4774
>>
Re: Curiosity how you use CouchDB in your web env.
Posted by David Rose <do...@gmail.com>.
Dale! Get in touch when you get here. 1 512 769 1392.
On Wed, Mar 6, 2013 at 4:17 PM, Dale Harvey <da...@arandomurl.com> wrote:
> After a long time trying to bend CouchApps into what I wanted it do it, I
> have eventually given up and now pretty much all my applications are
> webapps served from a plain webserver and talk to either couch directly or
> via some application logic written node
>
> Also I will be at SXSW picking up my badge next week, so see you there :)
>
> On 6 March 2013 22:59, David Rose <do...@gmail.com> wrote:
>
> > My most recent app, which we're using at SXSW for badge pickup, is a pure
> > CouchApp. If you're at SXSW, try and find me and I'll show it to you. Or,
> > look over the counter when you come pick up your badge.
> >
> > -David Rose
> > SXSW
> >
> >
> > On Wed, Mar 6, 2013 at 3:37 PM, svilen <az...@svilendobrev.com> wrote:
> >
> > > i'm trying to use couchdb as user-facing storage, message
> > > transport, as well as authentication. All changes=signals are handled
> > > via secondary pub-sub-dispatcher in python (somewhat like syncpoint).
> > > Clients replicate and talk to their own copies mostly.
> > > Still no escape from extra webapp/python layer - to click on the link
> > > in the confirmation email, accounts and all that webapp. Mostly
> > > achieving same fuctionality being triggered both via http as well
> > > as document-changes. i'm staying away from js although i do generate
> the
> > > js, java, objC, .. for models or view map/reduce funcs. Haven't put
> > > any thought on further scaling or wrapping. or validation of
> > > FiniteStateMachines that the app has turned into. or.. Maintenance.
> > >
> > > Though i'm quite stretched... as authentication is not
> > > well exampled, does not easy fit the
> > > multiple-changeable-keysets-per-user reality, and only plain
> > > usr/psw is 100% supported in mobile touchdb replications.
> > >
> > > but ce-la-vie. will invent something..
> > >
> > > svil
> > > www.svilendobrev.com/rabota/
> > >
> > > On Wed, 6 Mar 2013 15:20:29 -0500
> > > Simon de boer <sd...@ingamer.com> wrote:
> > >
> > > > It would be great to take out the application layer, but the need for
> > > > more Authorization controls in a relatively straight forward manner
> > > > would be key to having this work.
> > > >
> > > > There are many use cases where data for one user should be completely
> > > > impossible to access by another user. And the more complex case of
> > > > some data being conditionally private, ex. my friends can see my
> email
> > > > address, but it is private for all other users.
> > > >
> > > > Not only do these sort of inter-connections require more
> authorization
> > > > capability, but might require extreme engineering in order to wedge
> > > > them into the CouchDB paradigm.
> > > >
> > > > The other option is that some requests go direct to CouchDB, as in
> the
> > > > public items, but other items go through the application. Which is
> > > > entirely viable, but you would be have be working at such a scale to
> > > > make the overhead of maintaining this setup worthwhile.
> > > >
> > > > FWIW: I use a heavy Javascript client, Rails (Apache + Passenger),
> > > > MemCache, with data migrating on a feature by feature basis from
> MySQL
> > > > and to CouchDB. The eventual plan is to move to a much thinner
> > > > Application Server with data backed by Redis and CouchDB.
> > > >
> > > > On Wed, Mar 6, 2013 at 3:05 PM, Sean Copenhaver
> > > > <se...@gmail.com> wrote:
> > > > > I've made a site that was only a couchapp and enjoyed the
> > > > > experience quite a bit. I've also used it for internal tooling to
> > > > > store data and to host mini couchapps for search or utility pages.
> > > > >
> > > > > In all cases though security of data (at least I didn't care who
> > > > > could read the data) was not a requirement and I've greatly
> > > > > enjoyed my experiences. I would love to play around with gardener
> > > > > along with an OS daemon to try a tightly coupled nodejs + couchdb
> > > > > setup. Would also love to see CouchDB hosts to offer such things as
> > > > > well.
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Mar 6, 2013 at 2:51 PM, Dan Santner <da...@me.com>
> > > > > wrote:
> > > > >
> > > > >> I think it's brilliant as just a database and no more. So that's
> > > > >> how I use it. I have a similar setup to your #2. Perhaps that
> > > > >> just because I feel most comfortable with that type of setup.
> > > > >> This way I don't burden couch with anything security related. It
> > > > >> just eats and serves docs. My app tier handles the access control
> > > > >> and other tasks like email or any other services over the net that
> > > > >> I need to use.
> > > > >>
> > > > >>
> > > > >> On Mar 6, 2013, at 1:27 PM, Wendall Cada <we...@83864.com>
> > > > >> wrote:
> > > > >>
> > > > >> > We use couchdb in two configurations.
> > > > >> >
> > > > >> > 1. As a couchapp serving content for basic consumption. (For a
> > > > >> > url
> > > > >> shortener service)
> > > > >> > 2. As a database on localhost behind pylons or pyramid.
> > > > >> >
> > > > >> > To address the security question. We've been using couchdb for
> > > > >> > long
> > > > >> enough that it didn't have any security when we started using it
> in
> > > > >> production (0.8). Up until recently _users was a somewhat insecure
> > > > >> feature. It's only been with the release of 1.2.0 that _users is
> > > > >> handled securely.
> > > > >> >
> > > > >> > For our needs, couchdb still does not have robust enough acls
> > > > >> > for any of
> > > > >> our applications, so for now, it needs to run behind our app
> > > > >> servers. I see changes for this on the roadmap, but until this
> > > > >> actually happens, couchdb will happily sit on localhost serving
> > > > >> docs.
> > > > >> >
> > > > >> > I'm not sure why it isn't understood that based on it's history,
> > > > >> > CouchDB
> > > > >> has mostly been used as a database. I know people want it to be an
> > > > >> app server, but, in my opinion, that's the weakest part of the
> > > > >> entire system.
> > > > >> >
> > > > >> > Wendall
> > > > >> >
> > > > >> > On 03/06/2013 09:51 AM, Robert Newson 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 <au...@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
> > > > >> >
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > > --
> > > > > “The limits of language are the limits of one's world. “ - Ludwig
> > > > > von Wittgenstein
> > > > >
> > > > > "Water is fluid, soft and yielding. But water will wear away rock,
> > > > > which is rigid and cannot yield. As a rule, whatever is fluid, soft
> > > > > and yielding will overcome whatever is rigid and hard. This is
> > > > > another paradox: what is soft is strong." - Lao-Tzu
> > > >
> > > >
> > > >
> > > > --
> > > > Become the head coach with InGamer Sports!
> > > > http://www.InGamer.com/
> > > >
> > > > Simon de Boer
> > > > 519-400-4774
> > >
> >
>
Re: Curiosity how you use CouchDB in your web env.
Posted by Dale Harvey <da...@arandomurl.com>.
After a long time trying to bend CouchApps into what I wanted it do it, I
have eventually given up and now pretty much all my applications are
webapps served from a plain webserver and talk to either couch directly or
via some application logic written node
Also I will be at SXSW picking up my badge next week, so see you there :)
On 6 March 2013 22:59, David Rose <do...@gmail.com> wrote:
> My most recent app, which we're using at SXSW for badge pickup, is a pure
> CouchApp. If you're at SXSW, try and find me and I'll show it to you. Or,
> look over the counter when you come pick up your badge.
>
> -David Rose
> SXSW
>
>
> On Wed, Mar 6, 2013 at 3:37 PM, svilen <az...@svilendobrev.com> wrote:
>
> > i'm trying to use couchdb as user-facing storage, message
> > transport, as well as authentication. All changes=signals are handled
> > via secondary pub-sub-dispatcher in python (somewhat like syncpoint).
> > Clients replicate and talk to their own copies mostly.
> > Still no escape from extra webapp/python layer - to click on the link
> > in the confirmation email, accounts and all that webapp. Mostly
> > achieving same fuctionality being triggered both via http as well
> > as document-changes. i'm staying away from js although i do generate the
> > js, java, objC, .. for models or view map/reduce funcs. Haven't put
> > any thought on further scaling or wrapping. or validation of
> > FiniteStateMachines that the app has turned into. or.. Maintenance.
> >
> > Though i'm quite stretched... as authentication is not
> > well exampled, does not easy fit the
> > multiple-changeable-keysets-per-user reality, and only plain
> > usr/psw is 100% supported in mobile touchdb replications.
> >
> > but ce-la-vie. will invent something..
> >
> > svil
> > www.svilendobrev.com/rabota/
> >
> > On Wed, 6 Mar 2013 15:20:29 -0500
> > Simon de boer <sd...@ingamer.com> wrote:
> >
> > > It would be great to take out the application layer, but the need for
> > > more Authorization controls in a relatively straight forward manner
> > > would be key to having this work.
> > >
> > > There are many use cases where data for one user should be completely
> > > impossible to access by another user. And the more complex case of
> > > some data being conditionally private, ex. my friends can see my email
> > > address, but it is private for all other users.
> > >
> > > Not only do these sort of inter-connections require more authorization
> > > capability, but might require extreme engineering in order to wedge
> > > them into the CouchDB paradigm.
> > >
> > > The other option is that some requests go direct to CouchDB, as in the
> > > public items, but other items go through the application. Which is
> > > entirely viable, but you would be have be working at such a scale to
> > > make the overhead of maintaining this setup worthwhile.
> > >
> > > FWIW: I use a heavy Javascript client, Rails (Apache + Passenger),
> > > MemCache, with data migrating on a feature by feature basis from MySQL
> > > and to CouchDB. The eventual plan is to move to a much thinner
> > > Application Server with data backed by Redis and CouchDB.
> > >
> > > On Wed, Mar 6, 2013 at 3:05 PM, Sean Copenhaver
> > > <se...@gmail.com> wrote:
> > > > I've made a site that was only a couchapp and enjoyed the
> > > > experience quite a bit. I've also used it for internal tooling to
> > > > store data and to host mini couchapps for search or utility pages.
> > > >
> > > > In all cases though security of data (at least I didn't care who
> > > > could read the data) was not a requirement and I've greatly
> > > > enjoyed my experiences. I would love to play around with gardener
> > > > along with an OS daemon to try a tightly coupled nodejs + couchdb
> > > > setup. Would also love to see CouchDB hosts to offer such things as
> > > > well.
> > > >
> > > >
> > > >
> > > > On Wed, Mar 6, 2013 at 2:51 PM, Dan Santner <da...@me.com>
> > > > wrote:
> > > >
> > > >> I think it's brilliant as just a database and no more. So that's
> > > >> how I use it. I have a similar setup to your #2. Perhaps that
> > > >> just because I feel most comfortable with that type of setup.
> > > >> This way I don't burden couch with anything security related. It
> > > >> just eats and serves docs. My app tier handles the access control
> > > >> and other tasks like email or any other services over the net that
> > > >> I need to use.
> > > >>
> > > >>
> > > >> On Mar 6, 2013, at 1:27 PM, Wendall Cada <we...@83864.com>
> > > >> wrote:
> > > >>
> > > >> > We use couchdb in two configurations.
> > > >> >
> > > >> > 1. As a couchapp serving content for basic consumption. (For a
> > > >> > url
> > > >> shortener service)
> > > >> > 2. As a database on localhost behind pylons or pyramid.
> > > >> >
> > > >> > To address the security question. We've been using couchdb for
> > > >> > long
> > > >> enough that it didn't have any security when we started using it in
> > > >> production (0.8). Up until recently _users was a somewhat insecure
> > > >> feature. It's only been with the release of 1.2.0 that _users is
> > > >> handled securely.
> > > >> >
> > > >> > For our needs, couchdb still does not have robust enough acls
> > > >> > for any of
> > > >> our applications, so for now, it needs to run behind our app
> > > >> servers. I see changes for this on the roadmap, but until this
> > > >> actually happens, couchdb will happily sit on localhost serving
> > > >> docs.
> > > >> >
> > > >> > I'm not sure why it isn't understood that based on it's history,
> > > >> > CouchDB
> > > >> has mostly been used as a database. I know people want it to be an
> > > >> app server, but, in my opinion, that's the weakest part of the
> > > >> entire system.
> > > >> >
> > > >> > Wendall
> > > >> >
> > > >> > On 03/06/2013 09:51 AM, Robert Newson 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 <au...@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
> > > >> >
> > > >>
> > > >>
> > > >
> > > >
> > > > --
> > > > “The limits of language are the limits of one's world. “ - Ludwig
> > > > von Wittgenstein
> > > >
> > > > "Water is fluid, soft and yielding. But water will wear away rock,
> > > > which is rigid and cannot yield. As a rule, whatever is fluid, soft
> > > > and yielding will overcome whatever is rigid and hard. This is
> > > > another paradox: what is soft is strong." - Lao-Tzu
> > >
> > >
> > >
> > > --
> > > Become the head coach with InGamer Sports!
> > > http://www.InGamer.com/
> > >
> > > Simon de Boer
> > > 519-400-4774
> >
>
Re: Curiosity how you use CouchDB in your web env.
Posted by David Rose <do...@gmail.com>.
My most recent app, which we're using at SXSW for badge pickup, is a pure
CouchApp. If you're at SXSW, try and find me and I'll show it to you. Or,
look over the counter when you come pick up your badge.
-David Rose
SXSW
On Wed, Mar 6, 2013 at 3:37 PM, svilen <az...@svilendobrev.com> wrote:
> i'm trying to use couchdb as user-facing storage, message
> transport, as well as authentication. All changes=signals are handled
> via secondary pub-sub-dispatcher in python (somewhat like syncpoint).
> Clients replicate and talk to their own copies mostly.
> Still no escape from extra webapp/python layer - to click on the link
> in the confirmation email, accounts and all that webapp. Mostly
> achieving same fuctionality being triggered both via http as well
> as document-changes. i'm staying away from js although i do generate the
> js, java, objC, .. for models or view map/reduce funcs. Haven't put
> any thought on further scaling or wrapping. or validation of
> FiniteStateMachines that the app has turned into. or.. Maintenance.
>
> Though i'm quite stretched... as authentication is not
> well exampled, does not easy fit the
> multiple-changeable-keysets-per-user reality, and only plain
> usr/psw is 100% supported in mobile touchdb replications.
>
> but ce-la-vie. will invent something..
>
> svil
> www.svilendobrev.com/rabota/
>
> On Wed, 6 Mar 2013 15:20:29 -0500
> Simon de boer <sd...@ingamer.com> wrote:
>
> > It would be great to take out the application layer, but the need for
> > more Authorization controls in a relatively straight forward manner
> > would be key to having this work.
> >
> > There are many use cases where data for one user should be completely
> > impossible to access by another user. And the more complex case of
> > some data being conditionally private, ex. my friends can see my email
> > address, but it is private for all other users.
> >
> > Not only do these sort of inter-connections require more authorization
> > capability, but might require extreme engineering in order to wedge
> > them into the CouchDB paradigm.
> >
> > The other option is that some requests go direct to CouchDB, as in the
> > public items, but other items go through the application. Which is
> > entirely viable, but you would be have be working at such a scale to
> > make the overhead of maintaining this setup worthwhile.
> >
> > FWIW: I use a heavy Javascript client, Rails (Apache + Passenger),
> > MemCache, with data migrating on a feature by feature basis from MySQL
> > and to CouchDB. The eventual plan is to move to a much thinner
> > Application Server with data backed by Redis and CouchDB.
> >
> > On Wed, Mar 6, 2013 at 3:05 PM, Sean Copenhaver
> > <se...@gmail.com> wrote:
> > > I've made a site that was only a couchapp and enjoyed the
> > > experience quite a bit. I've also used it for internal tooling to
> > > store data and to host mini couchapps for search or utility pages.
> > >
> > > In all cases though security of data (at least I didn't care who
> > > could read the data) was not a requirement and I've greatly
> > > enjoyed my experiences. I would love to play around with gardener
> > > along with an OS daemon to try a tightly coupled nodejs + couchdb
> > > setup. Would also love to see CouchDB hosts to offer such things as
> > > well.
> > >
> > >
> > >
> > > On Wed, Mar 6, 2013 at 2:51 PM, Dan Santner <da...@me.com>
> > > wrote:
> > >
> > >> I think it's brilliant as just a database and no more. So that's
> > >> how I use it. I have a similar setup to your #2. Perhaps that
> > >> just because I feel most comfortable with that type of setup.
> > >> This way I don't burden couch with anything security related. It
> > >> just eats and serves docs. My app tier handles the access control
> > >> and other tasks like email or any other services over the net that
> > >> I need to use.
> > >>
> > >>
> > >> On Mar 6, 2013, at 1:27 PM, Wendall Cada <we...@83864.com>
> > >> wrote:
> > >>
> > >> > We use couchdb in two configurations.
> > >> >
> > >> > 1. As a couchapp serving content for basic consumption. (For a
> > >> > url
> > >> shortener service)
> > >> > 2. As a database on localhost behind pylons or pyramid.
> > >> >
> > >> > To address the security question. We've been using couchdb for
> > >> > long
> > >> enough that it didn't have any security when we started using it in
> > >> production (0.8). Up until recently _users was a somewhat insecure
> > >> feature. It's only been with the release of 1.2.0 that _users is
> > >> handled securely.
> > >> >
> > >> > For our needs, couchdb still does not have robust enough acls
> > >> > for any of
> > >> our applications, so for now, it needs to run behind our app
> > >> servers. I see changes for this on the roadmap, but until this
> > >> actually happens, couchdb will happily sit on localhost serving
> > >> docs.
> > >> >
> > >> > I'm not sure why it isn't understood that based on it's history,
> > >> > CouchDB
> > >> has mostly been used as a database. I know people want it to be an
> > >> app server, but, in my opinion, that's the weakest part of the
> > >> entire system.
> > >> >
> > >> > Wendall
> > >> >
> > >> > On 03/06/2013 09:51 AM, Robert Newson 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 <au...@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
> > >> >
> > >>
> > >>
> > >
> > >
> > > --
> > > “The limits of language are the limits of one's world. “ - Ludwig
> > > von Wittgenstein
> > >
> > > "Water is fluid, soft and yielding. But water will wear away rock,
> > > which is rigid and cannot yield. As a rule, whatever is fluid, soft
> > > and yielding will overcome whatever is rigid and hard. This is
> > > another paradox: what is soft is strong." - Lao-Tzu
> >
> >
> >
> > --
> > Become the head coach with InGamer Sports!
> > http://www.InGamer.com/
> >
> > Simon de Boer
> > 519-400-4774
>
Re: Curiosity how you use CouchDB in your web env.
Posted by svilen <az...@svilendobrev.com>.
i'm trying to use couchdb as user-facing storage, message
transport, as well as authentication. All changes=signals are handled
via secondary pub-sub-dispatcher in python (somewhat like syncpoint).
Clients replicate and talk to their own copies mostly.
Still no escape from extra webapp/python layer - to click on the link
in the confirmation email, accounts and all that webapp. Mostly
achieving same fuctionality being triggered both via http as well
as document-changes. i'm staying away from js although i do generate the
js, java, objC, .. for models or view map/reduce funcs. Haven't put
any thought on further scaling or wrapping. or validation of
FiniteStateMachines that the app has turned into. or.. Maintenance.
Though i'm quite stretched... as authentication is not
well exampled, does not easy fit the
multiple-changeable-keysets-per-user reality, and only plain
usr/psw is 100% supported in mobile touchdb replications.
but ce-la-vie. will invent something..
svil
www.svilendobrev.com/rabota/
On Wed, 6 Mar 2013 15:20:29 -0500
Simon de boer <sd...@ingamer.com> wrote:
> It would be great to take out the application layer, but the need for
> more Authorization controls in a relatively straight forward manner
> would be key to having this work.
>
> There are many use cases where data for one user should be completely
> impossible to access by another user. And the more complex case of
> some data being conditionally private, ex. my friends can see my email
> address, but it is private for all other users.
>
> Not only do these sort of inter-connections require more authorization
> capability, but might require extreme engineering in order to wedge
> them into the CouchDB paradigm.
>
> The other option is that some requests go direct to CouchDB, as in the
> public items, but other items go through the application. Which is
> entirely viable, but you would be have be working at such a scale to
> make the overhead of maintaining this setup worthwhile.
>
> FWIW: I use a heavy Javascript client, Rails (Apache + Passenger),
> MemCache, with data migrating on a feature by feature basis from MySQL
> and to CouchDB. The eventual plan is to move to a much thinner
> Application Server with data backed by Redis and CouchDB.
>
> On Wed, Mar 6, 2013 at 3:05 PM, Sean Copenhaver
> <se...@gmail.com> wrote:
> > I've made a site that was only a couchapp and enjoyed the
> > experience quite a bit. I've also used it for internal tooling to
> > store data and to host mini couchapps for search or utility pages.
> >
> > In all cases though security of data (at least I didn't care who
> > could read the data) was not a requirement and I've greatly
> > enjoyed my experiences. I would love to play around with gardener
> > along with an OS daemon to try a tightly coupled nodejs + couchdb
> > setup. Would also love to see CouchDB hosts to offer such things as
> > well.
> >
> >
> >
> > On Wed, Mar 6, 2013 at 2:51 PM, Dan Santner <da...@me.com>
> > wrote:
> >
> >> I think it's brilliant as just a database and no more. So that's
> >> how I use it. I have a similar setup to your #2. Perhaps that
> >> just because I feel most comfortable with that type of setup.
> >> This way I don't burden couch with anything security related. It
> >> just eats and serves docs. My app tier handles the access control
> >> and other tasks like email or any other services over the net that
> >> I need to use.
> >>
> >>
> >> On Mar 6, 2013, at 1:27 PM, Wendall Cada <we...@83864.com>
> >> wrote:
> >>
> >> > We use couchdb in two configurations.
> >> >
> >> > 1. As a couchapp serving content for basic consumption. (For a
> >> > url
> >> shortener service)
> >> > 2. As a database on localhost behind pylons or pyramid.
> >> >
> >> > To address the security question. We've been using couchdb for
> >> > long
> >> enough that it didn't have any security when we started using it in
> >> production (0.8). Up until recently _users was a somewhat insecure
> >> feature. It's only been with the release of 1.2.0 that _users is
> >> handled securely.
> >> >
> >> > For our needs, couchdb still does not have robust enough acls
> >> > for any of
> >> our applications, so for now, it needs to run behind our app
> >> servers. I see changes for this on the roadmap, but until this
> >> actually happens, couchdb will happily sit on localhost serving
> >> docs.
> >> >
> >> > I'm not sure why it isn't understood that based on it's history,
> >> > CouchDB
> >> has mostly been used as a database. I know people want it to be an
> >> app server, but, in my opinion, that's the weakest part of the
> >> entire system.
> >> >
> >> > Wendall
> >> >
> >> > On 03/06/2013 09:51 AM, Robert Newson 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 <au...@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
> >> >
> >>
> >>
> >
> >
> > --
> > “The limits of language are the limits of one's world. “ - Ludwig
> > von Wittgenstein
> >
> > "Water is fluid, soft and yielding. But water will wear away rock,
> > which is rigid and cannot yield. As a rule, whatever is fluid, soft
> > and yielding will overcome whatever is rigid and hard. This is
> > another paradox: what is soft is strong." - Lao-Tzu
>
>
>
> --
> Become the head coach with InGamer Sports!
> http://www.InGamer.com/
>
> Simon de Boer
> 519-400-4774
Re: Curiosity how you use CouchDB in your web env.
Posted by Simon de boer <sd...@ingamer.com>.
It would be great to take out the application layer, but the need for
more Authorization controls in a relatively straight forward manner
would be key to having this work.
There are many use cases where data for one user should be completely
impossible to access by another user. And the more complex case of
some data being conditionally private, ex. my friends can see my email
address, but it is private for all other users.
Not only do these sort of inter-connections require more authorization
capability, but might require extreme engineering in order to wedge
them into the CouchDB paradigm.
The other option is that some requests go direct to CouchDB, as in the
public items, but other items go through the application. Which is
entirely viable, but you would be have be working at such a scale to
make the overhead of maintaining this setup worthwhile.
FWIW: I use a heavy Javascript client, Rails (Apache + Passenger),
MemCache, with data migrating on a feature by feature basis from MySQL
and to CouchDB. The eventual plan is to move to a much thinner
Application Server with data backed by Redis and CouchDB.
On Wed, Mar 6, 2013 at 3:05 PM, Sean Copenhaver
<se...@gmail.com> wrote:
> I've made a site that was only a couchapp and enjoyed the experience quite
> a bit. I've also used it for internal tooling to store data and to host
> mini couchapps for search or utility pages.
>
> In all cases though security of data (at least I didn't care who could read
> the data) was not a requirement and I've greatly enjoyed my experiences. I
> would love to play around with gardener along with an OS daemon to try a
> tightly coupled nodejs + couchdb setup. Would also love to see CouchDB
> hosts to offer such things as well.
>
>
>
> On Wed, Mar 6, 2013 at 2:51 PM, Dan Santner <da...@me.com> wrote:
>
>> I think it's brilliant as just a database and no more. So that's how I
>> use it. I have a similar setup to your #2. Perhaps that just because I
>> feel most comfortable with that type of setup. This way I don't burden
>> couch with anything security related. It just eats and serves docs. My
>> app tier handles the access control and other tasks like email or any other
>> services over the net that I need to use.
>>
>>
>> On Mar 6, 2013, at 1:27 PM, Wendall Cada <we...@83864.com> wrote:
>>
>> > We use couchdb in two configurations.
>> >
>> > 1. As a couchapp serving content for basic consumption. (For a url
>> shortener service)
>> > 2. As a database on localhost behind pylons or pyramid.
>> >
>> > To address the security question. We've been using couchdb for long
>> enough that it didn't have any security when we started using it in
>> production (0.8). Up until recently _users was a somewhat insecure feature.
>> It's only been with the release of 1.2.0 that _users is handled securely.
>> >
>> > For our needs, couchdb still does not have robust enough acls for any of
>> our applications, so for now, it needs to run behind our app servers. I see
>> changes for this on the roadmap, but until this actually happens, couchdb
>> will happily sit on localhost serving docs.
>> >
>> > I'm not sure why it isn't understood that based on it's history, CouchDB
>> has mostly been used as a database. I know people want it to be an app
>> server, but, in my opinion, that's the weakest part of the entire system.
>> >
>> > Wendall
>> >
>> > On 03/06/2013 09:51 AM, Robert Newson 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 <au...@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
>> >
>>
>>
>
>
> --
> “The limits of language are the limits of one's world. “ - Ludwig von
> Wittgenstein
>
> "Water is fluid, soft and yielding. But water will wear away rock, which is
> rigid and cannot yield. As a rule, whatever is fluid, soft and yielding
> will overcome whatever is rigid and hard. This is another paradox: what is
> soft is strong." - Lao-Tzu
--
Become the head coach with InGamer Sports!
http://www.InGamer.com/
Simon de Boer
519-400-4774
Re: Curiosity how you use CouchDB in your web env.
Posted by Sean Copenhaver <se...@gmail.com>.
I've made a site that was only a couchapp and enjoyed the experience quite
a bit. I've also used it for internal tooling to store data and to host
mini couchapps for search or utility pages.
In all cases though security of data (at least I didn't care who could read
the data) was not a requirement and I've greatly enjoyed my experiences. I
would love to play around with gardener along with an OS daemon to try a
tightly coupled nodejs + couchdb setup. Would also love to see CouchDB
hosts to offer such things as well.
On Wed, Mar 6, 2013 at 2:51 PM, Dan Santner <da...@me.com> wrote:
> I think it's brilliant as just a database and no more. So that's how I
> use it. I have a similar setup to your #2. Perhaps that just because I
> feel most comfortable with that type of setup. This way I don't burden
> couch with anything security related. It just eats and serves docs. My
> app tier handles the access control and other tasks like email or any other
> services over the net that I need to use.
>
>
> On Mar 6, 2013, at 1:27 PM, Wendall Cada <we...@83864.com> wrote:
>
> > We use couchdb in two configurations.
> >
> > 1. As a couchapp serving content for basic consumption. (For a url
> shortener service)
> > 2. As a database on localhost behind pylons or pyramid.
> >
> > To address the security question. We've been using couchdb for long
> enough that it didn't have any security when we started using it in
> production (0.8). Up until recently _users was a somewhat insecure feature.
> It's only been with the release of 1.2.0 that _users is handled securely.
> >
> > For our needs, couchdb still does not have robust enough acls for any of
> our applications, so for now, it needs to run behind our app servers. I see
> changes for this on the roadmap, but until this actually happens, couchdb
> will happily sit on localhost serving docs.
> >
> > I'm not sure why it isn't understood that based on it's history, CouchDB
> has mostly been used as a database. I know people want it to be an app
> server, but, in my opinion, that's the weakest part of the entire system.
> >
> > Wendall
> >
> > On 03/06/2013 09:51 AM, Robert Newson 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 <au...@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
> >
>
>
--
“The limits of language are the limits of one's world. “ - Ludwig von
Wittgenstein
"Water is fluid, soft and yielding. But water will wear away rock, which is
rigid and cannot yield. As a rule, whatever is fluid, soft and yielding
will overcome whatever is rigid and hard. This is another paradox: what is
soft is strong." - Lao-Tzu
Re: Curiosity how you use CouchDB in your web env.
Posted by Dan Santner <da...@me.com>.
I think it's brilliant as just a database and no more. So that's how I use it. I have a similar setup to your #2. Perhaps that just because I feel most comfortable with that type of setup. This way I don't burden couch with anything security related. It just eats and serves docs. My app tier handles the access control and other tasks like email or any other services over the net that I need to use.
On Mar 6, 2013, at 1:27 PM, Wendall Cada <we...@83864.com> wrote:
> We use couchdb in two configurations.
>
> 1. As a couchapp serving content for basic consumption. (For a url shortener service)
> 2. As a database on localhost behind pylons or pyramid.
>
> To address the security question. We've been using couchdb for long enough that it didn't have any security when we started using it in production (0.8). Up until recently _users was a somewhat insecure feature. It's only been with the release of 1.2.0 that _users is handled securely.
>
> For our needs, couchdb still does not have robust enough acls for any of our applications, so for now, it needs to run behind our app servers. I see changes for this on the roadmap, but until this actually happens, couchdb will happily sit on localhost serving docs.
>
> I'm not sure why it isn't understood that based on it's history, CouchDB has mostly been used as a database. I know people want it to be an app server, but, in my opinion, that's the weakest part of the entire system.
>
> Wendall
>
> On 03/06/2013 09:51 AM, Robert Newson 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 <au...@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
>
Re: Curiosity how you use CouchDB in your web env.
Posted by Wendall Cada <we...@83864.com>.
We use couchdb in two configurations.
1. As a couchapp serving content for basic consumption. (For a url
shortener service)
2. As a database on localhost behind pylons or pyramid.
To address the security question. We've been using couchdb for long
enough that it didn't have any security when we started using it in
production (0.8). Up until recently _users was a somewhat insecure
feature. It's only been with the release of 1.2.0 that _users is handled
securely.
For our needs, couchdb still does not have robust enough acls for any of
our applications, so for now, it needs to run behind our app servers. I
see changes for this on the roadmap, but until this actually happens,
couchdb will happily sit on localhost serving docs.
I'm not sure why it isn't understood that based on it's history, CouchDB
has mostly been used as a database. I know people want it to be an app
server, but, in my opinion, that's the weakest part of the entire system.
Wendall
On 03/06/2013 09:51 AM, Robert Newson 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 <au...@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
Re: Curiosity how you use CouchDB in your web env.
Posted by Dan Santner <da...@me.com>.
Daniel. That's how I'd do it. In fact I'm doing something similar and I haven't found any performance trouble with the views yet, I also don't expect to have more than a few thousand docs per user and a few thousand users so I'm not real worried about scale. I think the critical thing is that you keep that org_id trapped in the app server so the front end can't modify and get access to another org's data.
On Mar 7, 2013, at 9:37 AM, Daniel Gonzalez <go...@gonvaled.com> wrote:
> 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 <rn...@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 <ma...@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 <rn...@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 <au...@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
>>>>
>>
Re: Curiosity how you use CouchDB in your web env.
Posted by Lance Carlson <la...@gmail.com>.
I use nginx in front node in front of couch. Perhaps this is overkill
but I'm most comfortable with nginx serving to the public. Node
handles security and background jobs. Couch the rest.
I actually was curious if anyone had done any benchmarks of using
templates/handlebars with couch vs using node. I'm still debating
which part of my stack should handle the views. In general I like
having my database serve everything but I'm seeing that my apps is
perhaps not as snappy as I'm used to. Perhaps this is not couch's
fault (although I've done several apps now using couch with the same
average request time). Can anyone share their experiences?
Sent from my iPhone
On Mar 8, 2013, at 4:32 AM, Stephen Bartell <sn...@gmail.com> wrote:
> This is interesting discussion.
> Couch is pretty powerful on its own. Powered by mochweb, its damn fast. The proxying and externals features are real sweet and lets one couch proxy to other couch's plus any web services. Given that, my stack is a bit different.
>
> For the product I work on, I put Couch behind nginx. Nginx serves all the web apps. I don't use any couch apps at all. It a world I've wanted to explore, but really have no reason since nginx is doing its job. I've never seen performance issues from nginx. The bottleneck usually is couch.
> Any special web services are usually node servers kept alive by forever. Nginx also proxies to them. I originally had couch proxy to these services, but in the end had nginx serve them instead.
> As for users, they have direct access to couch and have their own databases. I want to lean on Couch's security as much as possible. We originally considered having users share databases, and then use filtering to serve their docs, but that seemed like a nightmare. Heres my problems with that.
> 1) The data no longer belongs to the users. Each doc would need information about user rights
> 2) When user access rights change, a full reindex of views would need to take place. Imagine databases with millions of docs and rights changing somewhat frequently.
> 3) All indices would grow faster due to the fact that they would need to include a user level.
>
> Id love to hear if/how people are using the filtered shared database approach for multiple users.
>
> If I had it to do over again, its hard to say if I would have abandoned nginx and just used couch's proxy, externals, and couchapps I really like separating all the things. i.e., Couch as a datastore, nginx as a reverse proxy, web services controlled outside of couch. I'm either not seeing the light or ignorant.
>
> Who knows, maybe in a few years when I really learn to wield all things couch, I would be more comfortable in using couch all the way down.
>
> On Mar 7, 2013, at 7:06 PM, Lance Carlson <la...@gmail.com> wrote:
>
>> Keep me posted on your decision. I just node in front and also hit the same
>> node process with background processing. Very curious about what others are
>> choosing any why.
>>
>> On Thu, Mar 7, 2013 at 9:54 PM, Jeff Charette <io...@yahoo.com> wrote:
>>
>>> For my use case I would like to take advantage of couches replication and
>>> putting something in front of couch seems it complicate that. Also, I
>>> don't want couch to touch any credit information and simply like to pass
>>> through to a service. Externals seems a good use case for this, but node
>>> in front would get the job done as well. The more I think about it though
>>> I may put node in front because I have not been able to pass a POST request
>>> through externals.
>>>
>>> Jeff Charette | Principal
>>> We Are Charette
>>> web / identity / packaging
>>>
>>> m 415.298.2707
>>> w wearecharette.com
>>> e jeffrey@wearecharette.com
>>>
>>> On Mar 7, 2013, at 4:37 PM, Lance Carlson <la...@gmail.com> wrote:
>>>
>>>> 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 <ti...@gmail.com>
>>> wrote:
>>>>
>>>>> Anybody using couchdb as data layer with Grails?
>>>>>
>>>>>
>>>>> On Thu, Mar 7, 2013 at 11:38 AM, Jeff Charette <io...@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 jeffrey@wearecharette.com
>>>>>>
>>>>>> On Mar 7, 2013, at 10:57 AM, svilen <az...@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 <sn...@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: gonvaled@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 <rn...@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 <ma...@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
>>>>>>>>>>> <rn...@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 <au...@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
>
Re: Curiosity how you use CouchDB in your web env.
Posted by Lance Carlson <la...@gmail.com>.
To clarify, by client I meant node js, not the browser.
Sent from my iPhone
On Mar 8, 2013, at 4:32 AM, Stephen Bartell <sn...@gmail.com> wrote:
> This is interesting discussion.
> Couch is pretty powerful on its own. Powered by mochweb, its damn fast. The proxying and externals features are real sweet and lets one couch proxy to other couch's plus any web services. Given that, my stack is a bit different.
>
> For the product I work on, I put Couch behind nginx. Nginx serves all the web apps. I don't use any couch apps at all. It a world I've wanted to explore, but really have no reason since nginx is doing its job. I've never seen performance issues from nginx. The bottleneck usually is couch.
> Any special web services are usually node servers kept alive by forever. Nginx also proxies to them. I originally had couch proxy to these services, but in the end had nginx serve them instead.
> As for users, they have direct access to couch and have their own databases. I want to lean on Couch's security as much as possible. We originally considered having users share databases, and then use filtering to serve their docs, but that seemed like a nightmare. Heres my problems with that.
> 1) The data no longer belongs to the users. Each doc would need information about user rights
> 2) When user access rights change, a full reindex of views would need to take place. Imagine databases with millions of docs and rights changing somewhat frequently.
> 3) All indices would grow faster due to the fact that they would need to include a user level.
>
> Id love to hear if/how people are using the filtered shared database approach for multiple users.
>
> If I had it to do over again, its hard to say if I would have abandoned nginx and just used couch's proxy, externals, and couchapps I really like separating all the things. i.e., Couch as a datastore, nginx as a reverse proxy, web services controlled outside of couch. I'm either not seeing the light or ignorant.
>
> Who knows, maybe in a few years when I really learn to wield all things couch, I would be more comfortable in using couch all the way down.
>
> On Mar 7, 2013, at 7:06 PM, Lance Carlson <la...@gmail.com> wrote:
>
>> Keep me posted on your decision. I just node in front and also hit the same
>> node process with background processing. Very curious about what others are
>> choosing any why.
>>
>> On Thu, Mar 7, 2013 at 9:54 PM, Jeff Charette <io...@yahoo.com> wrote:
>>
>>> For my use case I would like to take advantage of couches replication and
>>> putting something in front of couch seems it complicate that. Also, I
>>> don't want couch to touch any credit information and simply like to pass
>>> through to a service. Externals seems a good use case for this, but node
>>> in front would get the job done as well. The more I think about it though
>>> I may put node in front because I have not been able to pass a POST request
>>> through externals.
>>>
>>> Jeff Charette | Principal
>>> We Are Charette
>>> web / identity / packaging
>>>
>>> m 415.298.2707
>>> w wearecharette.com
>>> e jeffrey@wearecharette.com
>>>
>>> On Mar 7, 2013, at 4:37 PM, Lance Carlson <la...@gmail.com> wrote:
>>>
>>>> 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 <ti...@gmail.com>
>>> wrote:
>>>>
>>>>> Anybody using couchdb as data layer with Grails?
>>>>>
>>>>>
>>>>> On Thu, Mar 7, 2013 at 11:38 AM, Jeff Charette <io...@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 jeffrey@wearecharette.com
>>>>>>
>>>>>> On Mar 7, 2013, at 10:57 AM, svilen <az...@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 <sn...@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: gonvaled@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 <rn...@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 <ma...@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
>>>>>>>>>>> <rn...@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 <au...@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
>
Re: Curiosity how you use CouchDB in your web env.
Posted by Stephen Bartell <sn...@gmail.com>.
This is interesting discussion.
Couch is pretty powerful on its own. Powered by mochweb, its damn fast. The proxying and externals features are real sweet and lets one couch proxy to other couch's plus any web services. Given that, my stack is a bit different.
For the product I work on, I put Couch behind nginx. Nginx serves all the web apps. I don't use any couch apps at all. It a world I've wanted to explore, but really have no reason since nginx is doing its job. I've never seen performance issues from nginx. The bottleneck usually is couch.
Any special web services are usually node servers kept alive by forever. Nginx also proxies to them. I originally had couch proxy to these services, but in the end had nginx serve them instead.
As for users, they have direct access to couch and have their own databases. I want to lean on Couch's security as much as possible. We originally considered having users share databases, and then use filtering to serve their docs, but that seemed like a nightmare. Heres my problems with that.
1) The data no longer belongs to the users. Each doc would need information about user rights
2) When user access rights change, a full reindex of views would need to take place. Imagine databases with millions of docs and rights changing somewhat frequently.
3) All indices would grow faster due to the fact that they would need to include a user level.
Id love to hear if/how people are using the filtered shared database approach for multiple users.
If I had it to do over again, its hard to say if I would have abandoned nginx and just used couch's proxy, externals, and couchapps I really like separating all the things. i.e., Couch as a datastore, nginx as a reverse proxy, web services controlled outside of couch. I'm either not seeing the light or ignorant.
Who knows, maybe in a few years when I really learn to wield all things couch, I would be more comfortable in using couch all the way down.
On Mar 7, 2013, at 7:06 PM, Lance Carlson <la...@gmail.com> wrote:
> Keep me posted on your decision. I just node in front and also hit the same
> node process with background processing. Very curious about what others are
> choosing any why.
>
> On Thu, Mar 7, 2013 at 9:54 PM, Jeff Charette <io...@yahoo.com> wrote:
>
>> For my use case I would like to take advantage of couches replication and
>> putting something in front of couch seems it complicate that. Also, I
>> don't want couch to touch any credit information and simply like to pass
>> through to a service. Externals seems a good use case for this, but node
>> in front would get the job done as well. The more I think about it though
>> I may put node in front because I have not been able to pass a POST request
>> through externals.
>>
>> Jeff Charette | Principal
>> We Are Charette
>> web / identity / packaging
>>
>> m 415.298.2707
>> w wearecharette.com
>> e jeffrey@wearecharette.com
>>
>> On Mar 7, 2013, at 4:37 PM, Lance Carlson <la...@gmail.com> wrote:
>>
>>> 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 <ti...@gmail.com>
>> wrote:
>>>
>>>> Anybody using couchdb as data layer with Grails?
>>>>
>>>>
>>>> On Thu, Mar 7, 2013 at 11:38 AM, Jeff Charette <io...@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 jeffrey@wearecharette.com
>>>>>
>>>>> On Mar 7, 2013, at 10:57 AM, svilen <az...@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 <sn...@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: gonvaled@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 <rn...@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 <ma...@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
>>>>>>>>>> <rn...@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 <au...@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
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>
>>
Re: Curiosity how you use CouchDB in your web env.
Posted by Lance Carlson <la...@gmail.com>.
Keep me posted on your decision. I just node in front and also hit the same
node process with background processing. Very curious about what others are
choosing any why.
On Thu, Mar 7, 2013 at 9:54 PM, Jeff Charette <io...@yahoo.com> wrote:
> For my use case I would like to take advantage of couches replication and
> putting something in front of couch seems it complicate that. Also, I
> don't want couch to touch any credit information and simply like to pass
> through to a service. Externals seems a good use case for this, but node
> in front would get the job done as well. The more I think about it though
> I may put node in front because I have not been able to pass a POST request
> through externals.
>
> Jeff Charette | Principal
> We Are Charette
> web / identity / packaging
>
> m 415.298.2707
> w wearecharette.com
> e jeffrey@wearecharette.com
>
> On Mar 7, 2013, at 4:37 PM, Lance Carlson <la...@gmail.com> wrote:
>
> > 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 <ti...@gmail.com>
> wrote:
> >
> >> Anybody using couchdb as data layer with Grails?
> >>
> >>
> >> On Thu, Mar 7, 2013 at 11:38 AM, Jeff Charette <io...@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 jeffrey@wearecharette.com
> >>>
> >>> On Mar 7, 2013, at 10:57 AM, svilen <az...@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 <sn...@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: gonvaled@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 <rn...@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 <ma...@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
> >>>>>>>> <rn...@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 <au...@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
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >>>
> >>
>
>
Re: Curiosity how you use CouchDB in your web env.
Posted by Jeff Charette <io...@yahoo.com>.
For my use case I would like to take advantage of couches replication and putting something in front of couch seems it complicate that. Also, I don't want couch to touch any credit information and simply like to pass through to a service. Externals seems a good use case for this, but node in front would get the job done as well. The more I think about it though I may put node in front because I have not been able to pass a POST request through externals.
Jeff Charette | Principal
We Are Charette
web / identity / packaging
m 415.298.2707
w wearecharette.com
e jeffrey@wearecharette.com
On Mar 7, 2013, at 4:37 PM, Lance Carlson <la...@gmail.com> wrote:
> 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 <ti...@gmail.com> wrote:
>
>> Anybody using couchdb as data layer with Grails?
>>
>>
>> On Thu, Mar 7, 2013 at 11:38 AM, Jeff Charette <io...@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 jeffrey@wearecharette.com
>>>
>>> On Mar 7, 2013, at 10:57 AM, svilen <az...@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 <sn...@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: gonvaled@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 <rn...@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 <ma...@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
>>>>>>>> <rn...@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 <au...@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
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>>>
>>
Re: Curiosity how you use CouchDB in your web env.
Posted by Lance Carlson <la...@gmail.com>.
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 <ti...@gmail.com> wrote:
> Anybody using couchdb as data layer with Grails?
>
>
> On Thu, Mar 7, 2013 at 11:38 AM, Jeff Charette <io...@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 jeffrey@wearecharette.com
> >
> > On Mar 7, 2013, at 10:57 AM, svilen <az...@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 <sn...@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: gonvaled@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 <rn...@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 <ma...@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
> > >>>>> <rn...@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 <au...@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
> > >>>>>>
> > >>>>
> > >>
> >
> >
>
Re: Curiosity how you use CouchDB in your web env.
Posted by Tim Anderson <ti...@gmail.com>.
Anybody using couchdb as data layer with Grails?
On Thu, Mar 7, 2013 at 11:38 AM, Jeff Charette <io...@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 jeffrey@wearecharette.com
>
> On Mar 7, 2013, at 10:57 AM, svilen <az...@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 <sn...@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: gonvaled@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 <rn...@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 <ma...@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
> >>>>> <rn...@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 <au...@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
> >>>>>>
> >>>>
> >>
>
>
Re: Curiosity how you use CouchDB in your web env.
Posted by Jeff Charette <io...@yahoo.com>.
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 jeffrey@wearecharette.com
On Mar 7, 2013, at 10:57 AM, svilen <az...@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 <sn...@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: gonvaled@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 <rn...@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 <ma...@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
>>>>> <rn...@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 <au...@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
>>>>>>
>>>>
>>
Re: Curiosity how you use CouchDB in your web env.
Posted by svilen <az...@svilendobrev.com>.
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 <sn...@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: gonvaled@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 <rn...@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 <ma...@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
> > > > <rn...@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 <au...@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
> > > >>
> > >
>
Re: Curiosity how you use CouchDB in your web env.
Posted by Daniel Gonzalez <go...@gonvaled.com>.
Several things:
- merging data is complicated. If your view does not provide the *exact*
data that your user needs to see, you will have trouble. For example, let's
say you have a list of events, and a list of contacts. Each event
corresponds to a given contact, but the name of the contact is not in the
event, just a refernce to it (because you want the user to edit the
contacts, and you do not want to modify all events when the contact has
been edited). So, to show the full data to the user you have to merge
events with contacts.
- serving those events in real time is difficult: you need to listen to
_changes in different databases, merge them, paginate in your application,
cache the result, and notify the client (via websocket for example).
Nooooot easy.
- maintenance in couchdb is difficult. Have you ever tried to correct a
problem in 1 million documents? Just finding the documents with problems is
a daunting task. (the same would apply to other databases, probably)
On the other hand, view access is very fast (once indexed), and replication
is very useful.
On Thu, Mar 7, 2013 at 4:47 PM, TAE JIN KIM <sn...@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: gonvaled@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 <rn...@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 <ma...@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 <rn...@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 <au...@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
> > > >>
> > >
>
>
RE: Curiosity how you use CouchDB in your web env.
Posted by TAE JIN KIM <sn...@hotmail.com>.
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: gonvaled@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 <rn...@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 <ma...@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 <rn...@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 <au...@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
> > >>
> >
Re: Curiosity how you use CouchDB in your web env.
Posted by Daniel Gonzalez <go...@gonvaled.com>.
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 <rn...@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 <ma...@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 <rn...@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 <au...@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
> >>
>
Re: Curiosity how you use CouchDB in your web env.
Posted by Matthieu Rakotojaona <ma...@gmail.com>.
On Wed, Mar 6, 2013 at 8:31 PM, TAE JIN KIM <sn...@hotmail.com> wrote:
> If you setup members on your database anonymous users can see the DB name
>> but they can't see/edit the documents.
>
> Are you sure about that?
> According to my testing, anonymous users still can see and edit (both) the documents, even though admin account was set up.
You need to couple accounts/roles with validate_doc_update :
https://wiki.apache.org/couchdb/Document_Update_Validation
--
Matthieu RAKOTOJAONA
Re: Curiosity how you use CouchDB in your web env.
Posted by Travis Paul <Tr...@visPaul.me>.
> even though admin account was set up.
Creating an admin account doesn't add security to your databases it just
takes you out of "admin party" mode, see:
http://wiki.apache.org/couchdb/Security_Features_Overview#Authorization
On Wed, Mar 6, 2013 at 2:31 PM, TAE JIN KIM <sn...@hotmail.com> wrote:
> If you setup members on your database anonymous users can see the DB name
> > but they can't see/edit the documents.
>
> Are you sure about that?
> According to my testing, anonymous users still can see and edit (both) the
> documents, even though admin account was set up.
>
> Thanks,
>
> > Date: Wed, 6 Mar 2013 14:21:04 -0500
> > Subject: Re: Curiosity how you use CouchDB in your web env.
> > From: Tr@visPaul.me
> > To: user@couchdb.apache.org
> >
> > >but still anonymous users still are able to read futon management
> > page(_utils) for all of database and documents...
> >
> > If you setup members on your database anonymous users can see the DB name
> > but they can't see/edit the documents.
> >
> > If you are concerned about users being able to access _utils in general,
> > even if they don't have rights to do anything you can use a reverse
> proxy,
> > though I can't think of any legitimate security reason too do so besides
> > (hiding database names) and there may be a better approach if that is
> what
> > you are after
> >
> > For example in nginx:
> >
> > location /_utils {
> > deny all;
> > }
> >
> >
> >
> > On Wed, Mar 6, 2013 at 2:11 PM, TAE JIN KIM <sn...@hotmail.com>
> wrote:
> >
> > > Let's suppose that you deployed your html to
> > > http://127.0.0.1:5984/testdb/_design/frontend/Index.htm served by your
> > > CouchDB directly.
> > > How do you set up in a way that anonymous users are only able to access
> > > _design/front-end, but nothing else like futon management pages(_utils)
> > > Looks like you may be able to set up an account, but still anonymous
> users
> > > still are able to read futon management page(_utils) for all of
> database
> > > and documents...
> > >
> > > Thanks,
> > >
> > > > Date: Wed, 6 Mar 2013 12:42:28 -0600
> > > > Subject: Re: Curiosity how you use CouchDB in your web env.
> > > > From: rnewson@apache.org
> > > > To: user@couchdb.apache.org
> > > >
> > > > 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 <ma...@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 <rn...@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 <au...@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
> > > > >>
> > >
> > >
>
>
RE: Curiosity how you use CouchDB in your web env.
Posted by TAE JIN KIM <sn...@hotmail.com>.
If you setup members on your database anonymous users can see the DB name
> but they can't see/edit the documents.
Are you sure about that?
According to my testing, anonymous users still can see and edit (both) the documents, even though admin account was set up.
Thanks,
> Date: Wed, 6 Mar 2013 14:21:04 -0500
> Subject: Re: Curiosity how you use CouchDB in your web env.
> From: Tr@visPaul.me
> To: user@couchdb.apache.org
>
> >but still anonymous users still are able to read futon management
> page(_utils) for all of database and documents...
>
> If you setup members on your database anonymous users can see the DB name
> but they can't see/edit the documents.
>
> If you are concerned about users being able to access _utils in general,
> even if they don't have rights to do anything you can use a reverse proxy,
> though I can't think of any legitimate security reason too do so besides
> (hiding database names) and there may be a better approach if that is what
> you are after
>
> For example in nginx:
>
> location /_utils {
> deny all;
> }
>
>
>
> On Wed, Mar 6, 2013 at 2:11 PM, TAE JIN KIM <sn...@hotmail.com> wrote:
>
> > Let's suppose that you deployed your html to
> > http://127.0.0.1:5984/testdb/_design/frontend/Index.htm served by your
> > CouchDB directly.
> > How do you set up in a way that anonymous users are only able to access
> > _design/front-end, but nothing else like futon management pages(_utils)
> > Looks like you may be able to set up an account, but still anonymous users
> > still are able to read futon management page(_utils) for all of database
> > and documents...
> >
> > Thanks,
> >
> > > Date: Wed, 6 Mar 2013 12:42:28 -0600
> > > Subject: Re: Curiosity how you use CouchDB in your web env.
> > > From: rnewson@apache.org
> > > To: user@couchdb.apache.org
> > >
> > > 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 <ma...@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 <rn...@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 <au...@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
> > > >>
> >
> >
Re: Curiosity how you use CouchDB in your web env.
Posted by Robert Newson <rn...@apache.org>.
You can also remove _utils from [httpd_global_handlers] but Futon is
not doing anything that an http request can't, it's *just* a UI.
B.
On 6 March 2013 13:21, Travis Paul <Tr...@vispaul.me> wrote:
>>but still anonymous users still are able to read futon management
> page(_utils) for all of database and documents...
>
> If you setup members on your database anonymous users can see the DB name
> but they can't see/edit the documents.
>
> If you are concerned about users being able to access _utils in general,
> even if they don't have rights to do anything you can use a reverse proxy,
> though I can't think of any legitimate security reason too do so besides
> (hiding database names) and there may be a better approach if that is what
> you are after
>
> For example in nginx:
>
> location /_utils {
> deny all;
> }
>
>
>
> On Wed, Mar 6, 2013 at 2:11 PM, TAE JIN KIM <sn...@hotmail.com> wrote:
>
>> Let's suppose that you deployed your html to
>> http://127.0.0.1:5984/testdb/_design/frontend/Index.htm served by your
>> CouchDB directly.
>> How do you set up in a way that anonymous users are only able to access
>> _design/front-end, but nothing else like futon management pages(_utils)
>> Looks like you may be able to set up an account, but still anonymous users
>> still are able to read futon management page(_utils) for all of database
>> and documents...
>>
>> Thanks,
>>
>> > Date: Wed, 6 Mar 2013 12:42:28 -0600
>> > Subject: Re: Curiosity how you use CouchDB in your web env.
>> > From: rnewson@apache.org
>> > To: user@couchdb.apache.org
>> >
>> > 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 <ma...@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 <rn...@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 <au...@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
>> > >>
>>
>>
Re: Curiosity how you use CouchDB in your web env.
Posted by Travis Paul <Tr...@visPaul.me>.
>but still anonymous users still are able to read futon management
page(_utils) for all of database and documents...
If you setup members on your database anonymous users can see the DB name
but they can't see/edit the documents.
If you are concerned about users being able to access _utils in general,
even if they don't have rights to do anything you can use a reverse proxy,
though I can't think of any legitimate security reason too do so besides
(hiding database names) and there may be a better approach if that is what
you are after
For example in nginx:
location /_utils {
deny all;
}
On Wed, Mar 6, 2013 at 2:11 PM, TAE JIN KIM <sn...@hotmail.com> wrote:
> Let's suppose that you deployed your html to
> http://127.0.0.1:5984/testdb/_design/frontend/Index.htm served by your
> CouchDB directly.
> How do you set up in a way that anonymous users are only able to access
> _design/front-end, but nothing else like futon management pages(_utils)
> Looks like you may be able to set up an account, but still anonymous users
> still are able to read futon management page(_utils) for all of database
> and documents...
>
> Thanks,
>
> > Date: Wed, 6 Mar 2013 12:42:28 -0600
> > Subject: Re: Curiosity how you use CouchDB in your web env.
> > From: rnewson@apache.org
> > To: user@couchdb.apache.org
> >
> > 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 <ma...@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 <rn...@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 <au...@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
> > >>
>
>
RE: Curiosity how you use CouchDB in your web env.
Posted by TAE JIN KIM <sn...@hotmail.com>.
Let's suppose that you deployed your html to http://127.0.0.1:5984/testdb/_design/frontend/Index.htm served by your CouchDB directly.
How do you set up in a way that anonymous users are only able to access _design/front-end, but nothing else like futon management pages(_utils)
Looks like you may be able to set up an account, but still anonymous users still are able to read futon management page(_utils) for all of database and documents...
Thanks,
> Date: Wed, 6 Mar 2013 12:42:28 -0600
> Subject: Re: Curiosity how you use CouchDB in your web env.
> From: rnewson@apache.org
> To: user@couchdb.apache.org
>
> 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 <ma...@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 <rn...@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 <au...@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
> >>
Re: Curiosity how you use CouchDB in your web env.
Posted by Robert Newson <rn...@apache.org>.
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 <ma...@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 <rn...@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 <au...@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
>>
Re: Curiosity how you use CouchDB in your web env.
Posted by Mark Hahn <ma...@hahnca.com>.
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 <rn...@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 <au...@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
>
Re: Curiosity how you use CouchDB in your web env.
Posted by Robert Newson <rn...@apache.org>.
"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 <au...@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
Re: Curiosity how you use CouchDB in your web env.
Posted by Aurélien Bénel <au...@utt.fr>.
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
Re: Curiosity how you use CouchDB in your web env.
Posted by Mark Hahn <ma...@hahnca.com>.
> I'd personally *hope* that most people are serving CouchDB directly
How does everyone solve the security issue? When I initially looked into
using couchdb from the browser I ran into a brick wall because I could
figure out no way to keep rogue JS code from trashing the DB. I do access
much of the http interface from the browser but I have to go through the
app to validate all requests.
On Wed, Mar 6, 2013 at 8:59 AM, Robert Newson <rn...@apache.org> wrote:
> "I think this is the most common setup." -- I'm not so sure, but I'd
> love to get some numbers.
>
> I'd personally *hope* that most people are serving CouchDB directly
> with the possible exception of a generic load balancer like HAProxy.
>
> B.
>
> On 6 March 2013 10:54, Dan Santner <da...@me.com> wrote:
> > I use couchdb as a restful doc persistence. I don't use CouchApp.
> > On Mar 6, 2013, at 10:45 AM, Mark Hahn <ma...@hahnca.com> wrote:
> >
> >> I have a node app that does all html serving and my app talks directly
> to
> >> couch via 127.0.0.1. I think this is the most common setup.
> >>
> >>
> >> On Wed, Mar 6, 2013 at 8:21 AM, TAE JIN KIM <sn...@hotmail.com>
> wrote:
> >>
> >>> There are couple of ways that CouchDB can be used in web development.
> >>>
> >>> You could deploy your html as attachment in _design in your couch
> db..so
> >>> actually couchdb could serve your html....
> >>> You could create a kind of proxy middle layer so that this can
> communicate
> >>> between your presentation layer and your CouchDB due to cross-domain
> issue
> >>> of Ajax..
> >>> There might be some different way as well....
> >>>
> >>> There is no obvious right answer approach here I guess, but just out of
> >>> curiosity, would like to hear
> >>> how CouchDB is being used in your web environment....
> >>> if you had all of experience as far as deployment is concerned, that
> would
> >>> be great if you could share for each pros/cons as well...
> >>>
> >>> Thanks in advance.
> >>>
> >>>
> >>>
> >>>
> >
>
Re: Curiosity how you use CouchDB in your web env.
Posted by Robert Newson <rn...@apache.org>.
"I think this is the most common setup." -- I'm not so sure, but I'd
love to get some numbers.
I'd personally *hope* that most people are serving CouchDB directly
with the possible exception of a generic load balancer like HAProxy.
B.
On 6 March 2013 10:54, Dan Santner <da...@me.com> wrote:
> I use couchdb as a restful doc persistence. I don't use CouchApp.
> On Mar 6, 2013, at 10:45 AM, Mark Hahn <ma...@hahnca.com> wrote:
>
>> I have a node app that does all html serving and my app talks directly to
>> couch via 127.0.0.1. I think this is the most common setup.
>>
>>
>> On Wed, Mar 6, 2013 at 8:21 AM, TAE JIN KIM <sn...@hotmail.com> wrote:
>>
>>> There are couple of ways that CouchDB can be used in web development.
>>>
>>> You could deploy your html as attachment in _design in your couch db..so
>>> actually couchdb could serve your html....
>>> You could create a kind of proxy middle layer so that this can communicate
>>> between your presentation layer and your CouchDB due to cross-domain issue
>>> of Ajax..
>>> There might be some different way as well....
>>>
>>> There is no obvious right answer approach here I guess, but just out of
>>> curiosity, would like to hear
>>> how CouchDB is being used in your web environment....
>>> if you had all of experience as far as deployment is concerned, that would
>>> be great if you could share for each pros/cons as well...
>>>
>>> Thanks in advance.
>>>
>>>
>>>
>>>
>
Re: Curiosity how you use CouchDB in your web env.
Posted by Johannes Jörg Schmidt <sc...@netzmerk.com>.
I love to reduce the server stack and use nothing more than CouchDB.
I often render HTML via show and list functions (mostly list functions) and
after the first hit I let the client take over.
2013/3/6 Dan Santner <da...@me.com>
> I use couchdb as a restful doc persistence. I don't use CouchApp.
> On Mar 6, 2013, at 10:45 AM, Mark Hahn <ma...@hahnca.com> wrote:
>
> > I have a node app that does all html serving and my app talks directly to
> > couch via 127.0.0.1. I think this is the most common setup.
> >
> >
> > On Wed, Mar 6, 2013 at 8:21 AM, TAE JIN KIM <sn...@hotmail.com>
> wrote:
> >
> >> There are couple of ways that CouchDB can be used in web development.
> >>
> >> You could deploy your html as attachment in _design in your couch db..so
> >> actually couchdb could serve your html....
> >> You could create a kind of proxy middle layer so that this can
> communicate
> >> between your presentation layer and your CouchDB due to cross-domain
> issue
> >> of Ajax..
> >> There might be some different way as well....
> >>
> >> There is no obvious right answer approach here I guess, but just out of
> >> curiosity, would like to hear
> >> how CouchDB is being used in your web environment....
> >> if you had all of experience as far as deployment is concerned, that
> would
> >> be great if you could share for each pros/cons as well...
> >>
> >> Thanks in advance.
> >>
> >>
> >>
> >>
>
>
Re: Curiosity how you use CouchDB in your web env.
Posted by Dan Santner <da...@me.com>.
I use couchdb as a restful doc persistence. I don't use CouchApp.
On Mar 6, 2013, at 10:45 AM, Mark Hahn <ma...@hahnca.com> wrote:
> I have a node app that does all html serving and my app talks directly to
> couch via 127.0.0.1. I think this is the most common setup.
>
>
> On Wed, Mar 6, 2013 at 8:21 AM, TAE JIN KIM <sn...@hotmail.com> wrote:
>
>> There are couple of ways that CouchDB can be used in web development.
>>
>> You could deploy your html as attachment in _design in your couch db..so
>> actually couchdb could serve your html....
>> You could create a kind of proxy middle layer so that this can communicate
>> between your presentation layer and your CouchDB due to cross-domain issue
>> of Ajax..
>> There might be some different way as well....
>>
>> There is no obvious right answer approach here I guess, but just out of
>> curiosity, would like to hear
>> how CouchDB is being used in your web environment....
>> if you had all of experience as far as deployment is concerned, that would
>> be great if you could share for each pros/cons as well...
>>
>> Thanks in advance.
>>
>>
>>
>>
Re: Curiosity how you use CouchDB in your web env.
Posted by Mark Hahn <ma...@hahnca.com>.
I have a node app that does all html serving and my app talks directly to
couch via 127.0.0.1. I think this is the most common setup.
On Wed, Mar 6, 2013 at 8:21 AM, TAE JIN KIM <sn...@hotmail.com> wrote:
> There are couple of ways that CouchDB can be used in web development.
>
> You could deploy your html as attachment in _design in your couch db..so
> actually couchdb could serve your html....
> You could create a kind of proxy middle layer so that this can communicate
> between your presentation layer and your CouchDB due to cross-domain issue
> of Ajax..
> There might be some different way as well....
>
> There is no obvious right answer approach here I guess, but just out of
> curiosity, would like to hear
> how CouchDB is being used in your web environment....
> if you had all of experience as far as deployment is concerned, that would
> be great if you could share for each pros/cons as well...
>
> Thanks in advance.
>
>
>
>