I have created a list of users in _Users database in couchDB, now I want to deactivate user, meaning the user cannot be logged into the the CouchDB. I do not want to delete the user from _Users database list, instead the user should not able to login. I am new to CouchDB can any one provide me the solution.
Perhaps you could change their password to a random value?
Related
I'm developing an application with NodeJS, ExpressJS and MongoDB. Currently I'm working on the user registration process. I would like to store the user account temporary until the user has verified his email address, if the email address is not verified within a certain amount of time, I would like to remove the temporary account.
Currently I've following two ideas to solve the issue:
Creating a mongoose TempUserModel (besides the UserModel), i.e. if the user does the registration a temp user will be created, as soon as the user verified his email address, the temporary user account will be copied to the real Users collection. Some cronjobs could be setup to delete not verified user accounts after a certain amount of time (probably there are better solutions to let expire a mongodb record)
Setup redis to store the temporary user account data, as soon as the email address get verified, a new user will be created in mongodb. With this solution an expire date could be set to remove not verified accounts after a certain amount of time)
Is it better to store a temporary user account in Redis or in MongoDB?
I would recommend storing the temporary user accounts in MongoDB. Storing them in MongoDB has three advantages over Redis:
If you store a temporary user in MongoDB, it will be very easy to convert them to a real user once they have verified. In fact, you could even have the temporary users and verified users share the same schema, with a has_verified field in that schema being the only difference between the two kinds of users. Changing has_verified to true is a lot easier than saving data from Redis to Mongo.
If you are not already planning to create a Redis database for your project, you will only have to maintain MongoDB. Maintaining MongoDB requires less effort and fewer computation resources than maintaining both Redis and MongoDB.
If you ever make changes to your user schema in the future, it would be easier to only make those changes in once place, i.e. MongoDB, rather than to make those changes in two places.
New to couchdb. I have a couchdb database, and then I have added users document to this database. I want to maintain uniqueness of both username AND email. If I had to check uniqueness of only one of those two fields I could use it directly as the _id value. But username or email address cannot have duplicate entries. How do I go about solving this?
Also, how does uniqueness work in a cluster scenario?
I know you can create new admin users via PUT $HOST/_config/admins/username -d '"password"'.
However, what if I have an existing user from the _users database and I want to add it to the
admin party?
The main problem here is that I don't know that user's password.
Thanks in advance,
Andres
Since the documents in the _users database contain password hash fields (derived_key, password_scheme, salt, password_sha, iterations) the hashes can be reused to create an admin using the raw=true parameter.
The hashed admin password format for PBKDF2 is as seen in the source code:
-pbkdf2-derivedkey,salt,iterations
For the SHA1 it is not quite clear which one is the hash and which one is the salt. Just try.
Note that the admin hashes are not stored in the _users database for a reason and reusing a password that was once exposed in this manner for an admin might be a bad idea security-wise.
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 would like to restrict the user permissions so that a normal user is only able to read/write its own user document.
I managed to set the write permissions such that a user can only edit their own document (via the validate_doc_update function in the design document).
Now I only have to limit a user from viewing the user list or other user documents. If I set the database read permissions to the '_admin' role, then the user will not be able to view their own document, which it's not what I intend.
Can this be done in a more general way? I.e. to set read permissions such that a user is able to read only some specific documents in the database?
Unfortunately, per-document read control is not possible.
However, if you use a list function you can perform a "post-query filter" that limits the results of a view query based on the current session user. (via the userCtx parameter)
In CouchDB creating a new database is cheap and it was designed to keep the data as close as possible to the user who needs it.
So the suggested approach is to have one database for each user.