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.
Related
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 a beginner programmer who has completed a Ruby on Rails bootcamp, but I have very little experience with PHP. I currently am developing an company training course using Moodle, and one of the requirements of the site is that each user will have their username and password displayed for them on a certain page in the course so that they can access a course-related App on their mobile devices. I have looked through the MoodleDocs and found nothing. Is there a way to do this?
No is the simple answer, the password is stored in the db using a md5 or sha1 hash, so its pretty much impossible to extract the password.
If you need to connect to another app, then use one of the external authentication methods.
If the database is on the same server then external database authentication is probably the easiest to set up
https://docs.moodle.org/27/en/External_database_authentication
You can show the users username using the global variable $USER
$USER->username;
But as others suggested is impossible to show password in clean text to the user.
Maybe Moodle Web services can help you achieve what you need
You can't access password as it is encrypted with md5 and sha1.
But, from what I understood from your question is that you want to authenticate user through your app on moodle. For this, you can take use moodle web services and moodle's auth plugins.
If you want to display the current user's username, you can do as follows:
global $USER;
echo $USER->username;
I am implementing an mobile app for android and iOS and I am using GAE with the datastore for persistance as the server side of my app. My app uses facebook login for user authentication. One of the key aspects of the app is that users can interact with each other through the app but I want to keep their actual facebook-id secret so that user cannot discover the facebook profile of another user through my app.
My original design for this was using MySQL and there I had a simple implementation of a users table with the table primary key, an auto-increment integer served as the user id for the app. So I could safely send the user id of other users to the client app, and this did not give away any information I did not want to give away. When a user logs in, the client app performs all the necessary facebook login procedures and sends the facebook access token to the server. The server would extract the facebook user information from this token chech if a user with this id already exists, if so use this user row, otherwise create a new one.
On an SQL database this works great since it is strongly consistent, and there is no way I will "miss" the fact that the user is already in the table. However now when I am using the eventual consistent datastore with the same idea, I ran into a problem where if a user logs in for the first time ever, an entry is added to the datastore, but then if the user logs in again shortly after the query I am performing to check if a "User" entity with the same facebook-id is already present this query sometimes still return no results. This leads to the same facebook id being assosiated with 2 different users of my app and this is obviously bad.
(I know this seems like an unlikely scenario, but I actually accidentally ran into it during development)
I thought of a few ways to mitigate this:
Instead of using the app user id as the entity key use the facebook id, this ensures consistency (since there is no index involved in the lookup now). This would imply I need to use the facebook id as the id for my app and this violates one of the design principles (the facebook id of other users will now leak to the client app).
Instead of relying on the datastore generated entity key id for the user, specify the id myself, by performing some sort of deterministic manipulation of the facebook user id, such as a hashing it or encrypting it. This way I can use the key to perform the lookup and no matter how many times the same user logs in their user id will be generated the same. But this seems like too heavy an approach to do correctly. If I hash it I will need to make sure to use a good hashing algorithm to prevent collisions. A good hash or encryption will output a long string as a user id, which is not too bad, but I would like to keep the user id as a simple long integer value if possible.
Accept the fact that this is eventually consistent, during a log in if we find more then one corresponding entity, delete them and stay with one. This is bad, because what if the user has already performed some operations that are stored on the previous entity? I will have to run through all the data for the multiple user entities from the same user and perform some sort of merging operation on them. This will also require me to run through other entities that store the user id and change them all.
Use memcache to store the user, this will probably make this scenario even more unlikely, but not eliminate it entirely. Memcache entries can be evicted prematurely, and in this case we are back to swaure one.
What is the best approach here? Is there something I am missing? Would really appropriate your input.
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.
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"