I wonder what's 'correct' way to create user accounts in MongoDB and actions like register/login. Do I have to create a specific collection for users (Username,Email,Password) or MongoDB has something built in already for users?
If I have to create users collection manually, how to deal with password encryption?
Thanks.
You'll probably have to create and manage the collection of users manually.
As for encrypting passwords, the common approach is to hash the passwords using a suitable hash-function before you store them in the db. Later, when a user tries to login you use the same hash-function on the string they entered in the password field and compare that result to the password entry in your db. That way you never store the actual passwords and if someone hacks you they won't get your users passwords, just their hashes.
For extra security (against dictionary attacks) you should also salt the hashed passwords. Read about it here
Mongo is for data persistance, what you are talking about is much higher level. A better question would be "How to do user authentication for <language or platform you are using> with mongo"
Related
I am developing a .NET Core, windows app with a PostgreSQL database and Entity Framework Core (ORM).
I have been trying to create logging in with username and password but I don't know how to bite it.
I have created roles in my database and table "User" with a username and hashed password column.
My main idea is to try to insert a username and password through UI, hash the password, create query checking the hashes, and here is my main problem I don't know what I should do when the passwords will match meaning that login was successful. Succesful login would somehow let the user of the app get a specific role in dB, that enables to read data from rows that match only one primary key of the user.
I don't know how to achieve this behaviour I thought that maybe using some kind of connection string for DbContext that have login and password of the user would be useful but I honestly have no idea.
If you are unsure how to setup the password handling for a Logged in functionality. Don't do it yourself, there are a lot of footguns and could go very badly. Use .Nets Identity, that will give you a good handling for these things.
I'm developing app for University. I will give each student a unique 10 digit Id for login(no email and password, student can just login using the given id). Now I need to restrict student to access only their data, not other students data. In firestore security rules is it possible with my implementation?
In PHP MySQL I can check it in the script, in Firebase it is still possible if I use cloud functions for all read and write operations. Is it is good practice to use cloud functions for all read and write operations?
As long as you mint a custom token for your users, Firebase Authentication will know about the user, and pass the information into the security rules of your database. Without such a custom token, there is no way to pass your information into security rules.
I am using mongo db to store user data, their passwords. I have two ways of creating an account:
Regular sign up when user selects username and password and
Sign up using facebook log in.
Now, when I have regular sign up, password and username should be required, but using facebook log in they are not, so I am wondering how I should now design a schema for the users model to include both cases?
The most obvious way seems like to have two different models: users_facebook and users_regular, but is it the right way to go? Why or why not? It could also be users_auth (auth data only for users who signed up manually) and users_data (both users' types data). There is also something like MongoDB Facebook Stitch that is somehow used for the purpose it seems, although I do not get what it is. I am very new to databases and not sure which is the right way to go. The problem seems though pretty trivial.
I am building a web-app with Meteor and i am using the Meteor Accounts-password package and accounts-facebook package to make login easy. The user has some information tied to them like email & password, but i want to tie more information to them after the account has been created.
I know of two ways that i could do that and i was wondering how i should do it, since i can't seem to find any information about it on the internet.
Option 1:
I add all the additional information (like username, displayname and other stuff) inside the Meteor.user.profile object. This seems to be a bad solution since users by default have access to everything in the profile object and i have to manually deny them access.
Option 2:
I create a new collection, Profile-information, and store all additional data about the user and then tie it to the meteor.user object via some shared key. This also seems like a bad solution since i have to split my data like in SQL and not have all the advantages of embedded documents in mongodb.
This has been my thought process so far and i am at a loss of how to continue.
Which option seems to be the best way, or is there an option 3 that would work better?
Thanks in advance.
Thanks to #forallepsilon i found out that you could write any data to the user object you want. I previously though that the user object was locked, and you could only store additional data in the profile field.
I will store the additional data i have about the user inside the Meteor.user object by just creating additional fields.
I am writing an ERM application using the Zend Framework in which user accounts are created under a main company account, enabling me to limit the number of user accounts for a company based on the license which the company paid for. Each company account has its own database (with identical structure to other companies) on my server to store data relevant to that company. The name of each companies database is stored in my "back end" database along with the rest of the companies account information and license key. The authentication system works as follows:
A new user (having never used the application before) lands on the index page and is greeted by a single text field for "Company Account Number"
After clicking "Submit", the next step in authentication is for username and password. When the user submits this form, all three pieces of information (account number, user name and password) are sent to my application's Authentication handler.
My "back end" database which stores company accounts is first queried to see if the account entered by the user exists. If it does, the company_db_name column is returned and a connection established then saved in the Zend_Registry. Otherwise, authentication has failed.
If the company account does exist, the database that was returned then has its users table queried for the specified username and password hash which either returns a successful instance of MyApp_Auth or false if the credentials were incorrect.
At first, I planned on storing user session data in the individual companies database, however I have run into the problem that there is no connection to this database when first landing on the application's index page. I have planned a workaround as follows:
Move my session storage table out of the customer's database to my "backend" database, which has a connection as soon as the application launches.
Add a "company account number" column to the table and index this column.
When a user lands on the application index page, the backend database can then be queried for the current user agent's sessionid. If it is found, then return all the necessary information i.e. the company database name to establish a connection, and the user's information to build a model with.
I have a couple questions regarding this approach:
Question 1 : Is there any risk in storing all session information for every user of my application in a single back-end database table? I am thinking in the multi-thousand user mindset.
Question 2 : I am concerned that a new user may visit the index page and by complete chance (understanding that this is a very low possibility, but still possible) have the same session_id as an existing session in the back-end database. Is this a valid concern, and if so, can it be mitigated?
Question 3 : Is there a better way, or would you recommend a different method to achieve my required functionality?
Thank you for your time!
To answer your 3 questions:
Answer 1. The is not risk as such for the storing session information of every user as long as you remove it on session expiration. The issue here is "scalability" what approach are you using? Is it scalable enough? What is the write/read speed? MySQL is 'structured' approach just like MSSQL. What processing time are you looking for? How much of information is stored? What is the architectural studies. Is it feasible enough for your client?
Answer 2. Ideally the session_id will not be the same so that should not be your concern.
Answer 3. You need NoSQL (Not Only SQL but, even more) approach. Read this
Looking at the MASSIVE-ness of your data, I strongly suggest you to go for HBASE (uses Hadoop, easy for multi cluster) or CouchDB or if you are Amazon fan dynamoDB.
Questions? :)
EDIT: Just realized you are using Zend Framework. In that case, you can also use MongoDB, and use Shanty Mongo library.