My website has a normal sign up and sign in process now I want to add google login (and later facebook, yahoo and ...) to my website but I'm not quiet sure how to change my user table.
Add all user info I get from google, facebook as new fields to my current users table? each login type gives me a first and a last name I just can keep one of them. the only user info to connect different login types with each other is the email address. So if a user has used different email for his/her facebook account than his gmail then each user will have lots of unused fields.
Using separate tables for each login types. have a google table, facebook table and ... and connect each record with a user in user table (if user has not signed up before google or facebook information will e used to create one). in this case user record will have a missing password field that of course can be resetted from account or by password forgotton function
which one is the correct way to do this?
Related
For two of my snowflake user accounts, an icon is showing up on the right that has a popup when I hover over it:
Why is this link showing up for two of my users?
Obviously I'm now confused about what these two "users" are and how they were created:
Are these users really service accounts?
If so, what is a snowflake service account and how does that differ from a user?
How do I designate some user accounts as service accounts and what are the pros/cons of doing so?
I've tried clicking the button and it just takes me to the user account details page and I don't see any "create user" type of language on the account details page.
I've tried to find anything in Snowflake's documentation that indicates a difference between service accounts and user accounts but I only find blog posts about how you need to treat your service accouns with care (and implement password rotation policies, etc).
I can't find anything definitive (yet) about designating users as "service acounts". (The closest thing is this stackoverflow about how service accounts are the same as normal user accounts.
Obviously there is something special about these two user accounts, though, since the snowflake UI is indicating these two users are actually service accounts.
The icon appears when a comment is set for the user. This comment can be set by yourself for a user to determine what is the purpose of it.
You may un/set it using the statements:
alter user user1 set comment='Create New User for Service Account';
alter user user1 unset comment;
More details: https://docs.snowflake.com/en/sql-reference/sql/alter-user.html#alter-user
In my application, a user can signup by completing a form or by using a provider (facebook, google, etc.). The main difference is that the user signing up by form will have a password, while the one using a social account will not.
I am not sure how to deal with the user model in the db. Should there be 2 separate tables, for each type of signup?
There is also the case of linking a normal account to a social account.
No a single table will suffice.
When the user signs up with the form, You save his info with the password he registered, And when he signs with the provider, You only save what the user allows you to save (email,profile picture, etc..).
And regarding the linking problem you can just make an option to merge accounts like here in stackoverflow.
I want to accomplish nearly the same thing as this question, which is to store authentication data from multiple sources (Facebook, Twitter, my own app, etc.) so that one person can log in to their account from any/all of the mentioned providers.
Following, I posted a screenshot of my two created tables.
The table "identity" will be responsible to store the login method (Facebook, Google or my own login system). An user can have one or more "identity".
In the table "identity", the column "adapter" will store the authentication method (facebook, google, myapp). The "hash" column will store the ID of the authentication method (for Google or Facebook), or if it's a record of my own app authentication method, the "hash" colunm will store the user registered password encrypted with SHA1.
My question is, for example: How can I detect if the user witch is authenticating through a Facebook account don't have already an "user" created with another authentication method? Because I don't want to create multiple users, to the same social auth account owner, or my own app account owner.
Can I get through this using the email column? So I can verify if the authenticating user already have a same e-mail registered in the "user" table, if he has, then I can create an identity with this same user_id?
If it is possible, I would recommend that you add the user before you add the identity id.
Check for existence of matching email before creating the user, then add the new identity.
I would have thought there should be a constraint on the identity that the user exists before creation. Otherwise you risk adding 'Identities' to the database with no connected user at all.
currently I need to provide web site logging for different social accounts (facebook, google, twitter and so on).
I know that stackoverflow has same system and I wonder if there is stackoverflow database model in public access. So I can find right way to store user data in my db.
Currently I have next problems.
So, I have my table for users:
UserID
UserName
RegistrationDate
Email
Rating
For users who create account with web site form I use next additional info:
Password
FirstName
LastName
Avatar
I stock in question how to store data for users who login with social networks and what should I store.
It seems that I dont need to store facebook name, surname and so on. I thought about getting it with js on pages where I need it.
Also I am thinking how to provide user with adding facebook, twitter references and so on for his profile.
P.S.
I am using DotNetOpenAuth for user authentication via social networks. Working with asp.net MVC 3.
About functionality on my web site:
just adding articles and rating for user.
For comments I use https://disqus.com/.
Ideally, you should have two tables. One for Users and one for Identities. In the Users table, you store things like your application user id, name, emails, etc. In the Identities table, you link back to the person in the User's table, but have a 'network' field that says which network the Identities row is for (e.g. Facebook, Google, Twitter, etc).
The Identities table can store the User ID and details specific to that platform, e.g. User_ID for Facebook, Twitter username, etc. The user will have one entry in the Users table, but can have many entries in the Identities table, depending on how many networks the user has connected with.
I have few tables like example.
Users Books UsersBookPurchase
UID BookId UserId
UName Name BookId
Password Price
Email
This is fine. I am having my own login system but i am also using some 3rd party to validate like OpenID or facebook Authetication. My question is if the user is able to log in successfully using OpenID or facebook Authentication, what steps do i need to do i.e do i have to insert one fake row in Users table because if i do not insert how will integrity be maintained. I mean what user id should i insert in UsersBookPurchase when the person who has logged in using Facebook Authentication has made a purchase because the UserId is reference key from Users table. Please give me a high level overview of what i need to do because this is fairly common scenario.
Thanks in advance :)
Basically yes. Don't think of it as a fake row. What you should do is to create an actual user account based on the data provided by Facebook API (I am not that familiar with OpenID)
Facebook API will provide you with first and last name, email address, maybe some other data
Facebook does not have the concept of login name, users login by email address.
What you do is just create a new user from the data provided by API.
There are some things to watchout for: it is possible that user is already registered on your site. When you get data from Facebook you should search your own user table to see if the email address already belongs to your own registered user and it that case you can do some fancy things like mark that user as also having a facebook login.
If I were to do that, I'd abstracted login info into a separate table and have some sort of type in the User table. The type is used to identify what auth method is used, i.e. your own, Google, etc. If a user does select using alternative methods, you do need to have association but with a different type. But yes it is a new record.