I have one table lets say TBL1 for registering the users and it contains close to 10 columns in it.I am adding all the new users to this table.Now for doing login for those users, should I point my DAO to this TBL1 for validating the users or I need to have separate table which will deal with login part.
Just a general doubt,whats the best way to maintain information about new user registration and validating users using register information.How do you register and allow users to login to your app ? are both insert and read happens from single table or from different tables ?
Here's the logic I would use:
I would register the NEW user in the registration table like you described above
When they fill out their username n password to login, I would first check for existence of that user in the registration table or TBL1. If they exist, then use their username and hashed password they used when they first registered from TBL1 or registration table to validate against their username and password on the client side i.e in browser window.
If those two don't match, i.e if the infos from the registration table doesn't match that provided in the login form on the client side, then you know they entered a wrong username or password.
To answer your question, you do NOT need a separate table for login users if you already have a registration table. You could use that registration table to do the validation when they go to log in. You can do both an INSERT and a READ to that same registration table, NO NEED for two tables there. Hope that helps you!
It depends on your requirement of application and security concerns. Of course creating a separate table for log in information is good practice.
If you have separate table for USERNAME and PASSWORD you can set limited rights on it. So only a specific part of your application can access it. And you can allow other registration details to be accessed more frequently if you need.
You might have some service that authenticate the user. So you can give access to only authentication and resetting password services for your log in table.
Even if you need to add or change something in your registration details it does not affect your authentication process at all.
It depends on Requirement and many factors of application:
Case 1: Requirement is small database having 10 tables, then you can maintain the login and registration information in the single table - TBL1.
Case 2: Requirement is big having say more than 10-20 tables, then it is good to use Normalized Level and so Create 2 different tables for registration and login and mapped with primary key.
Related
Maybe I am missing something here, or this is a flaw in Auth0? I'll give an example of my issue:
Let's say I have my Default App (client), hooked up to that I have Username-Password-Authentication (database connection) and google-oauth2 (social connection).
A user comes to my site, signs up via google-oauth2 (social connection) using joe#gmail.com. Once complete, he gets added to my users in Auth0, all great.
A few months later, Joe comes back to my site, and being a busy guy, he forgets he signed up to my site before. This time, he decides to sign up using my custom Email and Password form, that will add the user to the Username-Password-Authentication (database connection). so he signs up there using joe#gmail.com again, and everything goes well, he is now listed in my user's section in my Auth0 dashboard.
This is the problem, I now have two joe#gmail.com accounts, one with google-outh2 and one with Username-Password-Authentication. I really can't have this, I need a unique email address, regardless of the ID Auth0 supplies.
Does anyone know how I can make email address in my user section 100% unique? I'd think a rule would do this, but it appears rules only apply AFTER a user has been registered, so I can't run a rule before adding?
the only way I can see doing this right now is make my own checks and delete via the management API, but that is a really long and messy way to do it I feel.
Any help will be appreciated here!
Thanks!
Auth0's default behavior is to create a new account in the database for every unique entry. Since the user created using Google has a unique id (based on google-oauth2), and the user created using the sign-up form has a unique id - they will technically be considered two separate accounts. In order to resolve this disparity, you can establish a means with which the account data can be merged. In the documentation linked provided above, there are examples of three possible ways of doing this:
Automatic Linking - which involves creating a specific rule to merge users based on matching emails
User-Initiated Linking - which involves providing a UI for users to opt into merging users with matching emails
Suggested Account Linking - which involves setting up a rule that is linked into the UI
One important thing to consider is that the data returned from different social identity providers may not be normalized the way that data is normalized onto the Username-Password-Database. For example, while auth0's default for emails is to lowercase the information, google-oauth2 may return emails as Uppercased - creating the potential for non-matching emails when checks are made using strict equality
The option you are looking for is called account linking.
You can find more info at https://auth0.com/docs/link-accounts
Theoretically speaking, if I wanted to base my Users database table on the Auth0 returned data and maintain a unique ID in my Users table based on the Auth0 user profile id, will I ever encounter a situation where the Auth0 user id has been changed? If so, what are the situations when a user id changes?
The simple answer here is that the User Id will not change after creation for a given user profile in Auth0. However, there are a few other factors to consider, in particular:
Namespacing userids
Account linking
Auth0 will place a connection type prefix in-front of userIds to effectively namespace just the Id part - this is done with a pipe. For example, auth0|12345 or auth0|MyCustomDB|12345 etc. You need to ensure you use the entire userId, and not just the numeric value after the last pipe. The reason for this, is to ensure there are no collisions between Ids in IdP/Datastores in which Auth0 is the Service provider, & not the Identity Provider.
With regards to account linking, if you have two separate User Profiles - each has its own UserId. When you account link, one will become effectively the "primary" or "top-level" user profile, and the other profile becomes sub-ordinated as a "secondary" identity. And you can link multiple user profiles together as a single user profile in this way, but only one shall be the primary. You could consistently account link, so for example the DB Connection remains the primary, or you may just make the most recently created user profile (with a shared "email" in common to another profile) the primary... In this situation, the "tertiary" user profiles will retain their original userId, but if you were querying for the user profile only (and not trawling the identities array for that user profile also), then the effect on the search would appear to be the userId had changed. In actual fact, this is because what was originally a "top level" user profile, is now nested inside another use profile.
Finally, and slightly orthogonal to your original question - but where you state if I wanted to base my Users database table on the Auth0 returned data, hope here you were not referring to using the Auth0 user profile userId as a primary key in say a relational database. You would be better served creating a Surrogate key (unique key with no business meaning / outside dependency) as your primary key, Then store the Auth0 userId as a separate attribute on each tuple.
Hope the above made sense, please leave comments below if still unsure.
I am facing a problem trying to develop an application in Yii (v=1.1). Client wants the application to has multiple databases (one per his customer). That means that we will have unknown number of databases. Also He wants to have only one user authentication system - regard of it, users would have the choise (and the privilleges) to belong in many databases. So I am considering about the way which it could be developed.
Do you have faced something like this?
Well you should first better define your goal because it is not that clear to me what you want to accomplish, but how I see it.
Decide where you want to store the users:
Should the same user be able to connect using the same login info to two different customer databases?
Do you need to manage all users of all customers from one single place?
You could have the following situations:
Store users only in one common database, not in customer databases:
when logging in tell Yii to use the "common" database for the User model
you could have also a common application that handles user management
you could also provide the customer with the possibility to manage his own users
you could either have a "customer" field in the Users table to indicate to what customer it belongs, or you could have a "users_customers" table and after the login screen prompt the user with a "choose customer" screen, so one unique User can login to multiple Customers
Store users only in the customer databases:
if you don't need for a common place to manage users, or don't need to share them between customers, simply have a User table in every Customer database, this way user "alex" could exist in both databases with different login information
here you could simply add another field in the Login form (yes I've saw one application that does it) for example instead of Username and Password fields, ask for "Office, Username and Password", and the Office would be the name of the Customer database. Or you could even use only Username field and force users to enter something such as "alex#office" as Username, then you split that by "#" and you know to what office it belongs.
then simply use that information both on Login screen and on session to tell Yii what customer database to connect to
So as you see it could be done in different ways. Once you choose your way, you would need a implementation.
If you don't know how to do the implementation maybe I could provide more technical information related to Yii.
I have been doing some research about authentication and authorization on web api. I understand authentication (username/password) and ROLE based authorization, but what I'm confused about is authorization on data.
Say you have a user (user id 1) who is authenticated, an admin, and is associated to company ABC. I have other users associated to ABC which user id 1 can update. Now I want to update user id 2's name who is associated to ABC (which I should have access too). I need to pass in something to identify user 2, ie put /user/2 plus post data. I know on the server side that user 1 is allowed to update user 2 because he is authenticated and an admin.
Now I have user 100 who is associated to company XYZ. User 100 should not be able to update user 2. This is what I'm having a hard time finding information on.
What are some approaches/blogs/anything that can give some helpful ideas on how to prevent user 100 from accessing data outside it's company.
My thoughts are I could pass in the logged in users id (which I grab server side based on authentication) into the update stored procedure and do a check to make sure that user id is associated to the user being updated. To me this seems tedious and ugly in that every stored procedure needs a user id parameter and a check to make sure they can access the data they are accessing (maybe this is correct).
I know how to authenticate and how to check role based authorization, the missing part is resource based authorization.
Thanks for the help.
Does anyone have any insight. Its hard to believe that Role based Authorization is sufficient.
use the concept of authz where a user is prevented to see the details of other users
I have started building a web app that has different user types - including Admins and Customers, and I want each account type to have its own users db table (sessions system etc), but with the same log in page.
The Admins don't sign up - they are issued an account, whereas the Customer sign up on a page dedicated to creating their account, so at this time and in the future, every user account type will have its own sign up page.
Yet all user account types ie Admins and Customers, should be able to sign in from the same page - without any differences - in the log in form ie no drop down to select user account type being logged into.
My goals are to have:
all user account types (3+) log into web app via same form,
no need for any visible user account type identifier eg in the formatting of username,
as secure as possible 'invisible' user account type identifier.
One solution I've thought of is: hashing the passwords differently per user account type, but with some constant in the hash that can be read on sign in to identify the user account type, that then points the log in process to the right db for that user, but that would require some kind of constant in the hashed output... and I'm stuck. Am I on the right track?
Does anyone know of a script/how-to/or article that covers such a process somewhere?
This must be used in a lot of current web apps.
Thanks
Where we've had to implement multiple account types (in big systems I should stress) we always settle on a general (Users) table to supplement the additional tables (Administrators, WebUsers, Suppliers etc)
The Users table would link to either an Administrator, WebUser etc and any 'generic' functionality (i.e. login, logs, recordlocks) would link back to the generic Users table.
Then from a Users record you can deduce what type of account it is and decide what they can/cannot do.
I should stress though that this is only because the structure of these tables is so different that they cannot all be stored in the same table. If there's only 1 column different, for instance, you don't need to do all this.