On Sun, Jan 3, 2010 at 3:21 PM, Sam Bisbee wrote:
> On Sun, Jan 03, 2010 at 01:18:26PM -0800, Chris Anderson wrote:
>> On Sun, Jan 3, 2010 at 1:10 PM, Nathan Stott wrote:
>> > If a user can access a document via Futon, he can access via the CouchDB
>> > API
>> > if he knows what he's doing. The
On Sun, Jan 03, 2010 at 01:18:26PM -0800, Chris Anderson wrote:
> On Sun, Jan 3, 2010 at 1:10 PM, Nathan Stott wrote:
> > If a user can access a document via Futon, he can access via the CouchDB API
> > if he knows what he's doing. The data is exposed one way or the other if
> > you store it in d
On Sun, Jan 3, 2010 at 1:10 PM, Nathan Stott wrote:
> If a user can access a document via Futon, he can access via the CouchDB API
> if he knows what he's doing. The data is exposed one way or the other if
> you store it in documents that users can access. There is no key-level
> protection on a
On Sun, Jan 3, 2010 at 12:07 PM, Sam Bisbee wrote:
> On Sun, Jan 03, 2010 at 11:40:32AM -0800, Chris Anderson wrote:
>> I'd avoid thinking that hiding Futon provides security. Ideally users
>> would be able to get into the data via Futon if they choose. If you
>> structure your validation function
If a user can access a document via Futon, he can access via the CouchDB API
if he knows what he's doing. The data is exposed one way or the other if
you store it in documents that users can access. There is no key-level
protection on a document that I am aware of. Correct me if I'm wrong,
someo
On Sun, Jan 03, 2010 at 11:40:32AM -0800, Chris Anderson wrote:
> I'd avoid thinking that hiding Futon provides security. Ideally users
> would be able to get into the data via Futon if they choose. If you
> structure your validation functions properly, this should be
> completely secure (more secu
On Sun, Jan 3, 2010 at 11:21 AM, Karel Minařík wrote:
> Hi,
>
>> Everything except the throttling of deletes for a given user should be
>> easy to do natively with CouchDB.
>
> how about anyone accessing other databases, documents? Ie., I want to expose
> one database, containing the app (blog, wi
Hi,
Everything except the throttling of deletes for a given user should be
easy to do natively with CouchDB.
how about anyone accessing other databases, documents? Ie., I want to
expose one database, containing the app (blog, wiki, etc), but not
allow anyone browse databases, use Futon, et
On Sun, Jan 3, 2010 at 10:13 AM, Karel Minařík wrote:
> Hi,
>
>> On Jan 3, 2010, at 6:31 AM, Paweł Stawicki
>>>
>>> It is unevitable that if DB is accessible in the internet, everyone
>>> can edit/add/delete documents. After all, this is what I want. But I
>>> don't want to allow deletion of whol
Hi,
On Jan 3, 2010, at 6:31 AM, Paweł Stawicki
It is unevitable that if DB is accessible in the internet, everyone
can edit/add/delete documents. After all, this is what I want. But I
don't want to allow deletion of whole database. Or access to another
databases on the same CouchDB server.
On Sun, Jan 3, 2010 at 17:52, Sean Hess wrote:
> I'm brand new at this, so I don't know the common way to solve this,
> but I was thinking it should be possible to put it behind nginx or
> apache, and simply return a 503 code if they tried to hit your
> database url instead of a document.
Yes, th
I'm brand new at this, so I don't know the common way to solve this,
but I was thinking it should be possible to put it behind nginx or
apache, and simply return a 503 code if they tried to hit your
database url instead of a document.
If that doesn't work, you could always put a thin middleware la
Hello,
I am thinking about using CouchDB in app I want to create. In CouchDB
I can get documents directly from client's browser by javaScript and
it is great, but I have some concerns. I want the app to be accessible
to everyone without need to have an account or log in (like
wikipedia). If I want
13 matches
Mail list logo
