But you should be able to create a view and save it into a ddoc. And to do that you need the access to the database and the user credentials. If the web application is made in Python, for example, you don't even know it's using CouchDB, how can you think to create a view? This is just science fiction. We are talking of something you can do when you leave your database "open" to the world and this is not the case of any web application, unless you are using CouchDB to run couch apps or as a service. You can't run malicious code on my server, because you simply haven't access to CouchDB from a remote IP. If I'm using an Elixir, PHP, Ruby or Python query server, I'll never let you access to my database, because I'm developing the app in Elixir, PHP, Ruby or Python, you don't even know that I'm using CouchDB. If you are a company selling CouchDB as a service you want be sure no one can run malicious code on it, but if you are not, you really don't need a sandbox. I have a security question for you instead. The access to MySQL (or Oracle) can be configured per user by IP. Is this option available in CouchDB? This is really important, not the sandboxing of a query server.
-Filippo On Oct 16, 2013, at 11:16 PM, Benoit Chesneau wrote: > Sandboxing is not only needed for couchapps but also views. If someone > using a view inspect your hd and emit the result or send your docs using > a tcp connections to an unknown remote target it can be a risk. That's why > it's needed. Even allowed users can be a possible risk. > > - benoit
