I have been thinking on a procedure/method to activate user accounts in pre-filled database. Username and email pre-filled according to existing data.
Since the activation of the account is based on introducing only the user ID (which is know by the user and unique to each) and only clicking "Activate account", my best guess would be sending an URL containing an randomly unique generated activation code to the user mail (which was previously filled in the DB) which redirected to a webpage for choosing a password to the respective user account or automatically sending and e-mail containing a random password to the user's mail.
Is this the best suited method?
Related
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.
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?
I am looking to build a "reset password" function in my CakePHP app, and reading around the net I have decided to: Have the user type in their email address, send them an email with a link to http://www.mysite.com/users/reset_password/generated_uuid_that_expires_in_24_hours. This will present a form that allows them to change their password. Obviously the hiccup is that I don't know how to log the user in with a temporary password. Am I approaching this correctly? I am thinking that the url I send them would be a hashed version of their email plus a uuid to use as a temp password, and that I would perform a user id lookup based on the email that comes in the url....but still, I wouldn't know how to manually log them in so they can change their password.
I use the session approach.
after using the token from the email the user gets a
Tmp.User.id (as opposed to Auth.User.id)
in the session which will allow him to change the password.
afterwards it will be removed from the session again.
We have a forgot password system that allows a user to create a new password. It is going against Active Directory over LDAPS. Right now once a user goes to create a new password, we have to bind as an admin, change the password to a random string, then bind to the user account with that random string, then change the password to the one they provided. We do this because we have a password history policy of the last 5 used passwords.
This works fine now but the password history has the random strings as one of the previous passwords. Is there any way to bind with a user but without a password? The user would be authenticated before this by a security question.
I do it a different way. I create a dynamic object under the user's entry, expiring in a few days, with a generated uid attribute; send them a link containing that uid; that leads to the change password page, but logged in via a different LoginModule that sees the UID parameter, checks it, and if present and correct logs them in. In other words a kind of 'ticket' login.
The code that did the lookup bound/reconnected itself as the application itself, but that didn't actually matter because the connection for logging in is closed immediately, like all other LDAP connections in the application actually. When anything is done to the user's own entry, e.g. change password, update profile, a reconnect is done as that user using the password which I have saved in the session. When the user does anything else to LDAP it is really the application doing it so an application bind/reconnect is done as above. IOW the application itself is a user (or even several different users with different levels of permission).
Because a UID is much longer than a password, and because the entry containing it expires after a day or two, all this is rather more secure than generating a temporary password and shipping it around. The change password page could also have a security question on it if reached via the ticket login.
There are two password change operations in AD - reset and change. Reset is an administrative operation (which is what you are doing here). When you do a reset, you don't need to supply the current password. Change password is an end user operation whereby the user has to supply their current password in addition to the new password.
If you change your code to do a password reset and run in the context of a user with permissions to reset passwords, you should be good to go. If you need to honor password policy during the reset, there's a way to do this as well with a special LDAP control.