How to prevent anonymous users visit couchdb ?

[? ?]

Dear all,

I want to remotely manage couchdb by curl using the administrator account, but I found that anonymous users can also get some information , like _all_dbs, which is not what I want. It seems that couchdb allows anonymous users using GET and HEAD methods, so how can I prevent it? What I want is only administrators are allowed.

I have made the following settings in local.ini:
require_valid_user = true
WWW-Authenticate = Basic realm="administrator"

Thanks & regards,
Jinmin from Shanghai, China

[Joan Touzet]

Hi Jinmin.

Blocking /_all_dbs currently requires a reverse proxy with block rules in front of CouchDB.

We recommend haproxy for this use.

Best regards,
Joan Touzet from Toronto, Canada

[Moses Hohman]

Hi all,

In the spirit of "secure by default," would it be possible to change
CouchDB's default to require_valid_user = true? I think that's more
commonly what you'd want. Because it's fairly unusual that CouchDB allows
anonymous users and allows them to do significant things, it's liable to
surprise people and lead to misconfiguration.

Moses

[Joan Touzet]

Because it is such a large and backwards-incompatible change, we are intending to remove admin party and anonymous access with the 3.0 release. That release is not yet scheduled.


-Joan
----- Original Message -----

[明 淨]

It seems a little complex, maybe changing the listening port to 127.0.0.1 is a simple way, sacrifice remote access for security.

发件人: Joan Touzet<mailto:woh...@apache.org>
发送时间: Monday, April 23, 2018 11:18 PM
收件人: us...@couchdb.apache.org<mailto:us...@couchdb.apache.org>
主题: Re: How to prevent anonymous users visit couchdb ?

[明 淨]

Dear all,

I'm a newbie programmer from China, looking for a database which can satisfy my preferences. I have read an article about couchdb design, and like it very much, because it :

1. use javascript as the only programming language, no more other languages like **sql;
2. data format is json, no pre-defined schema;
3. support cluster replication, by additional updates;
4. support desktop and mobile;
.........
so many, not to list all

What I'm thinking about is the following things:

1. If I store the info of a person as a document in couchdb, will update of a few words in his/her self introduction cause the whole document to be rewrite? also, I have to submit the whole document to make this a few words update? Shall couchdb support field unit update in the future?

2. By default, a user of a database in couchdb can update all the documents in the database, but usually in the real world, every document has it's owner, and shouldn't be updated by users other than the owner. Is there any mechanism in couchdb to support document unit authorization?

3. As replication is the basis of data sync across cluster nodes, so will couchdb support field unit update in cluster data sync, not just document unit?

After all, I really like the design of couchdb, it's so simple and elegant, but I'm just a newbie and know very little about database world and database design, so I hope you can give me some guide so that I can get the right database according to my preferences.

Thank you all for reading my letter!

Best regards,
Jinmin

[Bill Stephenson]

Hi Jinmin,

> On Apr 25, 2018, at 7:11 PM, 明 淨 <jinm...@outlook.com> wrote:
>
> What I'm thinking about is the following things:
>
> 1. If I store the info of a person as a document in couchdb, will update of a few words in his/her self introduction cause the whole document to be rewrite? also, I have to submit the whole document to make this a few words update? Shall couchdb support field unit update in the future?

In a nutshell yes, you will update the entire document but that’s easy. You “get” the document as a JSON object and then update just the parts of the object you want and then “put” the updated document object back in the database.

>
> 2. By default, a user of a database in couchdb can update all the documents in the database, but usually in the real world, every document has it's owner, and shouldn't be updated by users other than the owner. Is there any mechanism in couchdb to support document unit authorization?

With CouchDB you can set it up so every user has their own database that only they can create, modify, and delete documents in. You can assign other users “roles” and add them to a database's “Permissions” that allow them to only read documents in a database as well.

>
> 3. As replication is the basis of data sync across cluster nodes, so will couchdb support field unit update in cluster data sync, not just document unit?

I don’t know the answer to this, but I do know you can replicate and sync databases between more than one CouchDB server. You don’t need a cluster to do that though.

I will suggest you take a look at PouchDB too. The info on their site will help you get a feel for some of the ways you can manage users and documents and permissions and you can use PouchDB in your web browser offline without a CouchDB server, and you can sync your web browser database with a remote CouchDB server, or just use PouchDB with a remote CouchDB server.

https://pouchdb.com

Also check out their “Authentication” plugin page to learn more about how you can manage users and database permissions on your CouchDB:

https://github.com/pouchdb-community/pouchdb-authentication/blob/master/docs/recipes.md

I hope this helps,

Bill

[明 淨]

Thank you, I will check Pouchdb.





________________________________
From: Bill Stephenson <bi...@cherrypc.com>
Sent: Thursday, April 26, 2018 9:37:42 AM
To: us...@couchdb.apache.org
Subject: Re: Some questions about couchdb

[Martin Broerse]

Perhaps also take a look at the https://bloggr.exmer.com exampe to see
CouchDB & PouchDB in action (https://github.com/broerse/ember-cli-blog)

[Harald Kisch]

Hi Jinmin,

as Bill answered already. Maybe there are two things worth to mention:
First: In 1 and 3 of your questions only the difference between the
document changes are stored to disk, not the whole document.
Second: Regular Knowledge of relational databases will not help you with
schemaless approaches of NoSQL Databases. In my experience so far, there
are a lot of confusing misunderstandings if you compare both approaches. If
you already have some deep Knowledge about relational databases, it would
be helpful for you to keep in mind, that at least CouchDB is not only
another way to store data.

Harry


On Thu, Apr 26, 2018 at 8:38 AM, Martin Broerse <martin....@gmail.com>
wrote:

--
--

Dipl.-Inf. Harald R. Kisch

Falkenstraße 19C
81541 München
Germany

Mobil DE: +49 (0) 176 56 58 58 38

Skype: harald.kisch
Mail: haral...@gmail.com

[明 淨]

Hi Harry,



Thank you for answering my question, in fact I don’t have deep knowledge about relational dbs, just very little.



It’s great that couchdb just store and sync among cluster nodes the changed part of a document, not the whole document, thanks.



About the second question, I think it might be impossible to create a separate database for each user if we have thousands of users for a website, and it also might not be a good solution to split some data into separate databases according to its owner, like articles created by users, generally, we keep all the articles in the same database. So does it mean that I shouldn’t use the _users database to keep users info?



Thanks & regards,

Jinmin







________________________________
From: Harald Kisch <haral...@gmail.com>
Sent: Thursday, April 26, 2018 4:45:29 PM
To: us...@couchdb.apache.org
Subject: Re: 答复: Some questions about couchdb

[明 淨]

Thank you for providing the information.





________________________________
From: Martin Broerse <martin....@gmail.com>
Sent: Thursday, April 26, 2018 2:38:41 PM

To: us...@couchdb.apache.org
Subject: Re: 答复: Some questions about couchdb

[Harald Kisch]

To give an answer to your second question:

The _users db holds the user documents with username and password-hash,
created when a user get registered.
I would not recommend to store user specific data there, typically you want
the users live in different systems with different user profiles.
Instead I would create encrypted user profile documents.

The reason for the concept of having a database per user is the fact that
in CouchDB everybody with access to the database is able to read each of
the stored documents.
(At this point, write access can be managed by document update function in
_design documents.)

You can regulate read access to databases only. Read access on document
level is not possible yet. If each of the users have their own database you
can regulate (in database security objects) which user and/or role has
access to it. From there documents can be replicated to a public database.

Another approach is to encrypt all data on each document but not the keys
used for map-reduce views. From there you can regulate access to encryption
keys on document level based on user profiles.
I would prefer the second approach like as you said, thousands of
user-databases leads to a high complexity at least in release management.

Cheers,
Harry

[Stefan Klein]

Hi Jinmin,

2018-04-26 2:11 GMT+02:00 明 淨 <jinm...@outlook.com>:

> 1. If I store the info of a person as a document in couchdb, will update of a few words in his/her self introduction cause the whole document to be rewrite? also, I have to submit the whole document to make this a few words update? Shall couchdb support field unit update in the future?

You could use an update handler for this case:
http://docs.couchdb.org/en/2.1.1/api/ddoc/render.html#db-design-design-doc-update-update-name

If it makes sense depends on the actual problem you're trying to solve.

> 2. By default, a user of a database in couchdb can update all the documents in the database, but usually in the real world, every document has it's owner, and shouldn't be updated by users other than the owner. Is there any mechanism in couchdb to support document unit authorization?

In addition to the one database per user approach, there also is the
validate_doc_update function:
http://docs.couchdb.org/en/2.1.1/ddocs/ddocs.html#vdufun

Again, it depends on the actual problem you're trying to solve.
If for example in your application everybody, maybe even anonymous
users, may read every document but only members of a specific role may
create and only "the owner" (how ever you determine it) may update a
document using validate_doc_update might be the way to go.

> 3. As replication is the basis of data sync across cluster nodes, so will couchdb support field unit update in cluster data sync, not just document unit?

Replication replicates whole documents, attachments are handled
differently, but don't worry to much about replication. It really just
works.

--
Stefan

[明 淨]

Thank you for the explanation, so I decide to not use the authentication mechanism provided by couchdb, and I will make it only listen on 127.0.0.1 so no one can access it by http, and all the authentication work will be done by website backend app like nodejs, which is a usual way.

发件人: Harald Kisch<mailto:haral...@gmail.com>
发送时间: Thursday, April 26, 2018 7:43 PM
收件人: us...@couchdb.apache.org<mailto:us...@couchdb.apache.org>
主题: Re: 答复: Some questions about couchdb

[明 淨]

Thank you for providing these information, I really need to learn more documents.





________________________________
From: Stefan Klein <st.fa...@gmail.com>
Sent: Thursday, April 26, 2018 8:05:13 PM
To: us...@couchdb.apache.org
Subject: Re: Some questions about couchdb