Geek Answers Handbook

Enable Open ID with my current login system?

I am currently setting up Open ID authentication on my website and am having problems with its current login system and database ... I read an article in Plaxo , and recommends that this type of table store openid information ...

create table user_openids ( openid_url varchar(255) not null, primary key (openid_url), user_id int not null, index (user_id) );

This is my current User Information table.

 Userid(PRIMARY) | username(UNIQUE) | password | Email

Userid is used to refer to user data for comments, ratings, etc. (Thus, it is included in the comments table and ratings table as a user identifier)

I want a system that looks like the stack overflow only uses login using your Open ID and gives you an unknown (OPENID provider) display name .... while saving my current login system. 1) How do I add the Open User ID data to the current "User Information" table without affecting the current login setting?
2) I am currently using a User-id (generated unique for each user) to store in a session to support login. What should I do now in case of Open ID?

* My thoughts (I don't know if I'm right or not)
- Add a public identifier field to store the unique public identifier URL provided by the public identifier provider for each user and set it to zero for non-public users. - Make User-id a text box and save the md5 of the id id URL (save it in a session to support logging in).
- I have no idea how I can handle a Display-name / Username that is unique for each user, because I would like to show the unknown (OPENID_provider) (for users using open-id) that can be changed from the settings profile ...

Any suggestions would be helpful .... Thanks

+4
source share
3 answers

The idea with the layout of the table you are showing is to have 1: many users: openids.

Thus, no changes to the user table are required.

When someone logs in with OpenID, you check to see if that OpenID is in the openids table. If so, you have the user_id of the user and you are done.

Otherwise, create a new user (without username and password) and insert the table (openid, user_id) into the openids table.

In the template, you can display any beautiful placeholder (for example, their OP or something else), where the username for users whose username is empty will usually be displayed.

I hope you have already banned login with empty passwords, so there should not be any security problems there.

+2
source

How about this?

  • Add a display_name column to the users table, which does not have to be unique.
  • Make username and password optional for users
  • When someone logs in with OpenID, create a line in users with an empty username / password and display name set to "unkonwn (provider)".
  • Allow users to set a username / password if they want to switch to password-based login.
  • Allow users to manage their OpenID so that existing users can switch to OpenID based login.

This means that users may have a username / password, but they do not need it. They may also have one or more OpenIDs, but they do not need this. They may use a non-unique display name.

+1
source

Option 1: only one input type is allowed

Here is my suggestion (UPDATED so that there is no need to edit all the business logic related to username ):

  • Create a new column called loginid to allow storage of OpenID and old usernames. Add UNIQUE INDEX to this column.
  • Pour loginid existing username data
  • DELETE INDEX from username so that they are not unique. When creating a new user from OpenID, set the username to unknown (google) as described.
  • Keep password for obsolete logs, ignore it for OpenID.
  • Only update the AUTH part of your code to look for a username, not a username.

Option 2: allow multiple logins (also easily applies to combining multiple profiles from different sources)

  • Create a new table that will stand as the table of the main users and will contain all the required fields for each user (perhaps the email from your example above).
  • Create a table for storing authentication that contains: userid ( FK for the master record), username (saves the username corresponding to the login scheme), password

There are obvious flaws in both of these options, but hopefully you will start in the right direction.

+1
source

More articles:


All Articles