I am very new to the CouchDB world! I have a database that can be read by all users, and also can edit the docs except for the design docs. Is there a way I can make a specific user edit only the doc that was created by him/her. I am using CouchApp nd the jquery.couch.js plugin
CouchDB doesn't have per-document permissions, only per-database permissions. If you grant write access to a user, he has write access to all the documents in the database.
Assuming you avoid making all users admin and that you use CouchDB's build-in authentication mechanism, I think that's the default behaviour.
For creating regular users, see Creating regular users in CouchDB.
For more details about how the user authentication and authorization actually works, see Security Features Overview, specifically the section below "Authentication database", which outlines the built in rules in CouchDB.
Only admin users can create new users, but there's nothing stopping your from having a program logging in and doing it automatically (using an admin user, this is assuming you are looking for some kind of "Registration" process where you would do for instance email validation through some other software of yours).
Related
I'm using strapi.
User registered with local api getting all data same as super admin.
How to implement or which plugin setting restricts, non-admin user to access data that he has added. (Similar to author-admin role)
This depends. Do you mean access their own data via the default Strapi backend? if yes, you could give them the Author role. Authors can always onle edit their own content.
If you mean access via REST API, you should be able to accomplish this with a policy, where you can restrict specific access based on your code entirely.
I'm just want to create a standalone application with CouchDB back-end, but I don't know if I can add a new (ordinary) user without using admin credentials.
In the documentation I just got information about creating an admin user and existing user's permissions:
Only administrators may browse list of all documents (GET
/_users/_all_docs) Only administrators may listen to changes feed
(GET /_users/_changes)
Only administrators may execute design functions like views, shows and
others
There is a special design document _auth that cannot be modified
Every document except the design documents represent registered
CouchDB users and belong to them
Users may only access (GET /_users/org.couchdb.user:Jan) or modify
(PUT /_users/org.couchdb.user:Jan) documents that they own
Here is the relevant part of documentation.
Short answer:
YES, you can
Makes no sense in a registration if you have to use admin credentials to create your account. Anyway, here is an example:
https://serverfault.com/questions/742184/couchdb-user-creation-without-authentication-standard-behavior
In this topic also can be useful this articol:
http://www.staticshin.com/programming/easy-user-accounts-management-with-couchdb
One more tip:
Creating regular users in CouchDB
We have c# web app connecting MongoDb deployed on Linux server. The idea is to use single designated Linux account for our web application to login and connect into MongoDb. As I understand from what I read, MongoDb does not support integrated security at all by default, it supposed to have its own user database with passwords, and no roles too, right? If so, I wonder if there is any separate third-party framework/tool or something that helps me use desired approach?
Other than that, if you know good online article regarding best practices to implement Security for Mongo in web applications, like where and how to store users and encrypted passwords etc., please give me a link.
please give me a link.
I did some security documentation a few months ago for MongoDB and it can be found here, this should be your starting point.
As I understand from what I read, MongoDb does not support integrated security at all by default, it supposed to have its own user database with passwords, and no roles too, right?
Up until MongoDB 2.2, authentication and authorisation is all local.In 2.2, there is limited RBAC (Role Based Access), i.e. two roles "read" and "write", with "write" being able to do everything on that database, i.e. admin.
Things will change in 2.4 with new roles:
name description of privilege
read ability to query data in any collection in the database, other than 'system.users', and also ability to run any command without an A or W attribute
readWrite everything permitted by 'read' privilege, and also the ability to insert, update,
or remove documents or indexes in any collection other than 'system.users', and also the ability to run any command without an A attribute
userAdmin ability to read and write the 'system.users' collection
dbAdmin ability to run admin commands affecting a single database; see list below
serverAdmin ability to run admin commands affecting the entire database server; Can only be set on admin database; see discussion
clusterAdmin admin commands for a cluster of shards or a replica set; Can only be set on admin database
as documented here. This enhanced RBAC will be available in all versions of MongoDB from 2.3.2 (development build) and the next production release, 2.4.0.
With MongoDB 2.4, there will also be the ability to use Kerberos for authentication, however, this delegated authentication will only be available in the Enterprise builds, which require a Commercial Support contract for us.
There is currently nothing within MongoDB that enforces password complexity but obviously in 2.4 with Kerberos, the KDC can do this. You will manually have to ensure (through your internal password policy etc) that users realise the issues of using non-complex passwords and re-using the same passwords on multiple devices. Assuming you are running 2.2, all logins, passwords and permissions for MongoDB access are stored in the system.users collection under each database. Here is the exact link to the documentation that you should read.
I did read http://guide.couchdb.org/draft/security.html and
and the previous question
CouchDB Authorization on a Per-Database Basis
and
http://wiki.apache.org/couchdb/Security_Features_Overview
I am currently using Apache CouchDB 1.2.0 and via futon the adding an admin result in
adding a user at _users for example
_id
org.couchdb.user:stackoverflow
_rev
1-b9f223532b662d4ac52d14082d81e6a5
name
stackoverflow
password
null
roles
[ ]
type
user
So the first question is why the admin is added as type user and not admin is puzzling. This users are admin as they can do anything in any database and the role is empty BUT I did protect the _users document with
["admin"]
roles as the only members and only admins can access this (even if their role in the _users document is empty).
This protection does not allow new "normal" users to be created so the futon "signup" command will return Signup error: You are not authorized to access this db.
I think this setup is the only logical one. Why would you want anyone to be able to create a user on your database ??
Even if you specify read access in a db to be only for one admin every admin can access it
(
" admins" : {
"names" : ["guru"],
"roles" : ["boss"]
},
"readers" : {
"names" : ["guru"],
"roles" : ["boss"]
}
}
the above case has no impact on the newly created stackoverflow admin as per above example.
So my assumption is that admins created via futon can do everything and anything regardless. The only confusing logical part is the _users documents where they have no special type (they are users) nor a special role.
So back to the concrete question:
- when adding an admin via futon why is it not marked as admin inside the _users document and how does CouchDB from that document determine that it is a wide system admin?
- if you want to create a normal user WITHOUT allowing them to signup (via futon or direct HTTP Request) you have to protect the _users document. Yet how would you go to create yourself a user to read/write on his own database ?
- As the user (per CouchDB Docs) will have the read/write rights on a DB but not the possibility to create design documents how can he really use it efficiently as views will be needed for anyone developing using the DB?
It should be possible to have a normal, simply multi hosting without jeopardizing security as there is a shared CouchDB offering at http://www.iriscouch.com/ so I just don't understand how logically you would structure a simple service where a user has his own database and can do anything but just on this database. As the admin role is anyway "user" how would you distinguish them from a non admin in the _users table ?
Why is the admin added as a normal user and not an admin?
CouchDB is similar to Windows's Active Directory, or Unix NIS and LDAP: most users have "normal" accounts, however the admin account (e.g. Windows "Administrator", or Unix "root") does not use the normal accounting system, but rather a much simpler system (the local.ini config file).
If the account and authentication system ever has a problem, you can still log in as the admin and fix it.
Do I need to add the "_admin" role to a user?
No, the admin role (the role "_admin") does not come from the user's document, but only from the configuration, in the "admins" section.
How come all admins can read the database?
By creating an admin in the global configuration (either editing the local.ini file, or using Futon's "Configuration" tab, or clicking the "Fix this" link in Admin Party), you created a system admin. System admins have access to all data, always (similar to Windows Administrator and Unix root).
CouchDB supports database admins which are normal users. Those users have admin access only to a database, not to anything else, such as other databases, or the server config. Database admins are set in the "Security" section, by adding a user's name or role to the "Admins" lists.
The concrete question: - when adding an admin via futon why is it not marked as admin inside the _users document and how does CouchDB from that document determine that it is a wide system admin?
When adding an admin via Futon, two things happen
A normal user is created (with no valid password in fact)
The same user name is added to the system configuration "admins" section. GET /_config/admins/the_username to see it. (That's what Futon's configuration tab does.)
In other words, CouchDB does not know it is a wide system admin from the document but rather from the config. If you delete that config entry, the user is "demoted" back to a normal user.
Side note about Iris Couch
It can be a little confusing at first, but the CouchDB user and security system is pretty simple and powerful once you learn it. But each Iris Couch users have entire CouchDB servers. If you sign up, you have an account at Iris Couch, but you have an entire CouchDB server to use. Inside that server, you can create multiple users for your own applications.
I've been playing with Iris Couch using Futon, curl and reading the CouchDB security Wiki page and I'm a little confused about readers, admins & server admins.
Am I correct in saying that the "Create Server Admin" pop-up in Futon isn't actually creating a server admin, (the wiki mentions this is only done by editing a local.ini file)?
What you're really doing is creating documents in the _users database - giving users a username & password to authenticate with, after which their name or role is compared to any names/roles defined against a database security object?
Also, I noticed that the "require_valid_user" is set to false by default, so assuming Iris Couch has a server admin, does this mean that although users have to provide their username/password to authenticate - they're validated as anonymous, so no comparison is made against any database-defined security?
If I want to restrict a user to a specific database, do I need the "require_valid_user" setting to be set to true?
Cheers
When you use the "Create server admin" popup form, that is the same as editing the .ini files. (Internally, Futon will query the a /_config URL which is an HTTP API to edit the .ini files.)
The _users database is the authoritative location for all user acounts, their passwords, and their roles. When a user queries CouchDB with a password (or with a session cookie), that name and role will be used to grant or deny their query. The decision of whether to allow or disallow their query is made by checking the _security object in the database first. They must be in the "readers" section: either their name is in the "names" list, or their role must be in the "roles" list.
I recommend that you avoid the require_valid_user option. It is for very specialized situations.
You can have database-specific users and roles. You need to modify the _security "document" for a given database. It's also documented here on the wiki.