39

私のアプリケーションには、次の構造を持つ「ユーザー」テーブルがあります。

CREATE TABLE IF NOT EXISTS `users` (
  `userId` int(10) unsigned NOT NULL auto_increment,
  `username` varchar(128) NOT NULL default '',
  `password` varchar(32) NOT NULL default '',
  `email` text NOT NULL,
  `newsletter` tinyint(1) NOT NULL default '0',
  `banned` enum('yes','no') NOT NULL default 'no',
  `admin` enum('yes','no') NOT NULL default 'no',
  `signup_ip` varchar(20) NOT NULL default '',
  `activation_key` varchar(60) NOT NULL default '',
  `resetpassword_key` varchar(60) NOT NULL default '',
  `createdon` datetime NOT NULL default '0000-00-00 00:00:00',
  PRIMARY KEY  (`userId`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=27 ;

StackOverflow が行ったように、Facebook、Twitter、および OpenID を介したソーシャル ログインをアプリケーションに実装したいと考えています。既存のログイン機能とともに、DB に必要なすべての変更と、PHP でのロジックの実装方法を提案してください。

ありがとう！

4

1 に答える 1

52

の概念を導入することをお勧めしますAuthenticationProvider。

CREATE TABLE IF NOT EXISTS `AuthenticationProvider` (
`ProviderKey` varchar(128) NOT NULL,
`userId` int(10) unsigned NOT NULL,
`ProviderType` enum('facebook','twitter', 'google') NOT NULL, 
PRIMARY KEY  (`ProviderKey`) )  
ENGINE=MyISAM  DEFAULT CHARSET=latin1;

各ログイン プロバイダーは、ユーザーに一意のキーを提供します。これは に保存されProviderKeyます。には、ProviderTypeこれがProviderKey属するログイン プロバイダに関する情報が含まれており、最後に、userId列はその情報をusersテーブルと結び付けます。そのため、ログイン プロバイダの 1 つから正常なログインを受け取ったらProviderKey、テーブルで対応するものを見つけて、問題のユーザの認証 Cookie を設定します。

を にしたいのかどうかわかりませProviderTypeんenum。これらを保持できる別のテーブルを作成する方がおそらく正しいでしょう。

たとえば、ユーザーが最初にサイトに登録し、Facebook 経由でログインする場合、usersテーブルに行を作成する必要があります。passwordただし、 、activation_keyおよびresetpassword_key関与はありません。そのため、これらのフィールドを別のテーブルに移動して、usersテーブルに主要なユーザー データのみが含まれ、単一のログイン メカニズム (ユーザー名/パスワード) にのみ関連するデータが含まれないようにすることができます。

これが理にかなっており、正しい方向に向けられていることを願っています。

/クラウス

于 2011-01-25T12:27:06.730 に答える