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?
Related
Hi I working on a simple application using Azure CosmosDB. Now I want to use resource tokens to provide specific access to documents and collection in the DB. In the permission modes there are PermissionMode.Read and PermisssionMode.All. So I am assuming that PermissionMode.All allows the users to read, write, delete and post. If what I am assuming is correct, I specifically do not want my users to delete or post in a certain collection. How do I achieve this?
For better understanding, my database contains a container called users, which contains user information along with their posts and likes per post and stuff. Now I allow all my users to read (view posts of other users) and write (give a like or increment the like field), but I want to allow Post and Delete to a document to only the user of the document.
The finest granularity for assigning permissions is a partition key value so the only way to grant per document permissions is if your document id is also the partition key. If your partition key is userId and the user profile and posts, etc. all share that same partition key then that should work for you. Here is a sample that creates a permission on a partition key for a user.
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?
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.
I am currently developping a platform with a PHP framework for our client.
The head of the client's IT department wants us to handle authentication with one database field containing email+password+salt (hashed) so there isn't a plain text email field in this table and the password is more secure (his reasoning). The user should be able to login with his email address and password. So the email address serves as the username.
The idea behind this is that the email addresses of the users are very important for the business of our client and the IT head wants to obscure the email address in the login table in case of a possible attack. (e.g. a hacker gets access to the login table)
This is of course only possbile, because the hashed email adress for the login is linked to his email address in the profile table.
Basically there are two tables which are required for this process to work. The tables are in the same database of course.
One login table with the hash combination field (email, pw, salt) and one profile table which contains among other things the email in plaintext in one field. Let's call it profile_email.
I have strongly recommended not to use this solution, because I have never before heard of this and I have already identified some possible problems with this solution.
So my questions are: Is this a safe and feasible solution? Can you think of any unforeseeable problems? Have you heard of similar solutions?
from an entity-relationship-point-of-view ...
you have a login table that either contains a field that is a concatination of hashes or a hash of a concatination of string values ...
you have a profile table that conatins the usual profile info, including a sensitive info (email)
if those two are linked by a key, the simple hashing of that email address is useless, since the same info is available as a clear text string from the profile table
in the other case, when in the login table it is ONE hash of a concatination of email password and salt, it is no added security, since the link to the profile table reveals a part of the hashed concatination ... since you also have to store the salt, and since that also has to be linked to the login entity or be part of the login entity, an attacker knows all parts of the concatination except the password ...
i can't see why this approach is a good idea, except if you split the database login for authentication from the rest ...
let's say you have in your login table:
s=randomSalt
e=cryptoHash(email,static_system_wide_salt)
p=cryptoHash(password,s)
id=KeyForRelationToOtherEntities
now the database rights to this table are restricted, and only the authenticator_user may access it, but nothing from the rest of the database
the email address in the authentication process is hashed and hardened against rainbowtable attacks
the password too
you can index the e colum for searching during the login process
the authenticator can not access profile information or other information that can be linked to the login entity, since the access rights restrict the authenticator to the login table
the rest of the system can't access the login table for the same reason
one additional role has to be taken into account, regarding password changes and creating new users if the authenticator may only read the login table
... just my 2 cents here ... it's just an idea, and not really complete, or guaranteed to be secure ... just an idea that picks up the general idea of separating the login table
I'm not absolutely clear about your scenario, but i guess it's something like this:
valueToStore = hash(email) + delimiter + hash(password, salt) + delimiter + salt;
This would allow to search for the email, but only if the email is made case insensitive (e.g. lower case). Otherwise you could even get duplicates with the same e-mail address.
Because the hashed email is only part of this field, searching in the database is more difficult and slower. If the user changes his email address, you would have to update both fields, the password table and the profile_email table.
Because the email is available in another table anyway, it is incomprehensible why this should be more secure. If an attacker has read access to the database (e.g. SQL-injection), there is nothing to prevent him from query the other table too.
It would be more safe, if the email would be encrypted (not hashed) in the other table too. Then you can search for the email by hash and nevertheless encrypt the email with an IV.
In every case i would not store the hashed email and the password-hash into a single field. If hashed correctly then other parameters like cost factor and algorithm are also part of the password-hash, this is enough for a single field.
I have my _users database secured, so a user can only access their own information. However, I'd like other users to be able to retrieve certain public information such as email addresses, real names, and phone numbers. What's the best way I can go about accomplishing this?
You can store the info in the _local database, e.g. _local/userinfo.json. Of course you need to know the url of the other users.