> potential botnets Are you telling me that there was a design consideration to keep couch from being used in a bad way?
On Fri, Jul 29, 2011 at 11:14 AM, Max Ogden <[email protected]> wrote: > security: potential botnets. your other option is to copy whatever api you > are hitting into couch ahead of time. I think philosophically couch is > designed to hold data and not access it through limited access APIs > > On Fri, Jul 29, 2011 at 1:55 PM, Michael <[email protected]> wrote: > > > I was afraid of that. Right now that is exactly what I am doing, but I > hate > > the idea of needing to move an application wherever I replicate the > > database, which is one of the major reasons I choose Couch. Client site > is > > not an option due to choked mobile bandwidth, utter lack of information > > without the external API. > > > > Is there a reason for the no external request rule? Security, technology > or > > has it just not been a priority? > > > > Thanks for the response, > > > > Michael > > > > > > On Fri, Jul 29, 2011 at 1:25 PM, Max Ogden <[email protected]> wrote: > > > > > CouchDB can't make requests to other domains from a show function. You > > will > > > have to put an application layer such as node.js, python flask or ruby > > > sinatra on top of Couch or do the request in client side javascript to > > > achieve what you are seeking. > > > > > > Max > > > > > > On Fri, Jul 29, 2011 at 1:09 PM, Michael <[email protected]> wrote: > > > > > > > This has been a problem I have been looking at for a long time and my > > > > current solution is not elegant at all, so I am hoping that you all > > might > > > > help. > > > > > > > > I have a show and I would like to make a request to another API (from > > > > another domain) from the show, which I would like combine that data > and > > > the > > > > data from Couch into my response. This feels like it should be easy, > > but > > > I > > > > cannot find any examples of this happening. > > > > > > > > Any help would be much appreciated. > > > > > > > > Thanks, > > > > > > > > Michael > > > > > > > > > >
