Struttura del database per l'implementazione del login sociale?

Question

Nella mia applicazione, ho una tabella "utente" che ha la seguente struttura.

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 ; 

Voglio realizzare login sociale attraverso facebook, twitter e OpenID nella mia richiesta, proprio come ha fatto StatckOverflow. Per favore suggeriscimi quali cambiamenti richiederò nel mio db e in che modo la logica verrà implementata in PHP, insieme alla funzione di accesso esistente.

Grazie!

Answer 1

Vorrei suggerire che si introduce il concetto di 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; 

Ogni provider di accesso fornisce una chiave unica per l'utente. Questo è memorizzato in ProviderKey. Lo ProviderType contiene informazioni su quale provider di accesso appartiene a ProviderKey e, infine, la colonna userId accoppia le informazioni con la tabella users. Pertanto, quando si riceve un accesso di successo da uno dei provider di accesso, si trova il corrispondente ProviderKey nella tabella e si utilizza il cookie di autenticazione per l'utente in questione.

Non sono sicuro di volere che lo ProviderType sia un enum. Probabilmente sarebbe più corretto fare un altro tavolo che potesse contenere questi.

Quando un utente si registra per la prima volta con il sito e accede tramite Facebook, ad esempio, è necessario creare una riga nella tabella users. Tuttavia, non saranno coinvolti password, activation_key e resetpassword_key. Quindi potresti voler spostare quei campi su una tabella separata, in modo tale che la tabella users contenga solo i dati dell'utente principale e nessun dato rilevante solo per un singolo meccanismo di accesso (nome utente/password).

Spero che questo abbia senso e che punti nella giusta direzione.

/Klaus

Answer 2

Take a look at openidexplained.com per le prime spiegazioni.