Att ange ett användarnamn och lösenord är ett sätt att komma åt ett konto, men det är inte det enda. I den här artikeln kommer vi att se hur du aktiverar externa tjänster (som Google eller Facebook) när du loggar in på en databas.
Vad är inloggningar för externa tjänster?
Att ge en användare möjlighet att komma åt sina systemkonton via externa tjänster är en växande trend bland webbdesigners. Det här alternativet kan ge flera fördelar, som att ge användarna en mindre kombination av namn och lösenord att komma ihåg. Det kan också hjälpa administratörer att anpassa användarupplevelser.
När webbapplikationer erbjuder en extern tjänstinloggning ser inloggningsskärmen ut som på bilden nedan. En användare kan ange sitt användarnamn och lösenord, eller så kan de klicka på en knapp som omdirigerar dem till den tjänst de väljer (Facebook, Twitter, Google, etc.) där de loggar in och omdirigeras till den ursprungliga applikationen.
Här är ett exempel på inloggningsskärmen från Vertabelo Academy:
Så fungerar externa inloggningar
Att lägga till externa inloggningstjänster kräver en del extra arbete från utvecklarna. De flesta populära sociala medietjänsterna använder ett protokoll som heter OAuth 2.0 . Endast Twitter använder ett äldre protokoll som heter OAuth 1.0 . Protokollet möjliggör läsning av användarinformation som deras fullständiga namn, e-post, kön, etc. Den exakta informationen som är tillgänglig beror på sociala medietjänster och vad användaren än tillhandahållit. (Det är till exempel möjligt att ha ett Facebook-konto utan en bifogad e-postadress.) Oavsett, men vi kommer att fokusera på hur man implementerar detta system i designen av en databas.
Som utgångspunkt kommer vi att använda vår tidigare artikel om lösenordsåterställning och e-postbekräftelse som bas. Här är de användarrelaterade tabellerna från den här artikeln.
Designa en databas för externa inloggningar
Mycket information i user_account tabellen är relaterad till hantering av autentisering – plus relaterade funktioner som lösenordspåminnelse och e-postbekräftelse – på egen hand. Vi behöver inte dessa kolumner om användaren autentiserar med en extern tjänst. Lösenordspåminnelsen, e-postbekräftelsen och andra funktioner hanteras av den externa tjänsten. Det första steget i vår design är att separera user_account tabell i två tabeller:user_account och user_profile .
user_account table sköter nu all sin egen autentiseringsbokföring. user_profile Tabellen representerar den faktiska användarinformationen:namn, e-post, tidszon, godkännande av användarvillkor och så vidare. Alla företagstabeller bör nu vara relaterade till user_profile bord.
Nu till externa konton. OAuth protokollet ger oss i slutändan en identifierare för användaren i deras system. Denna identifierare är inte användarens namn i det externa systemet. Det är bara en identifierare för vår applikation. Vi måste lagra detta interna ID i vår databas. Vi skulle kunna lägga till nollbara kolumner facebook_id , google_id , twitter_id , etc. till tabellen user_profile . Men vi kommer att göra något annat.
Vi kommer att lägga till nya tabeller:facebook_account , twitter_account , google_account , som lagrar det externa ID:t. På så sätt, om vi behöver, kan vi lägga till ytterligare information specifikt för varje social webbplats. Om vi vill lägga till en inloggningsmöjlighet för en annan social webbplats behöver vi inte ändra user_profile tabell. Vi kommer bara att lägga till ytterligare ett external_service_account bord.
Var och en av de nya tabellerna delar samma kolumnformat. En av dem kommer att vara int user_profile_id , som både är en främmande nyckel som refererar till id-kolumnen i user_profile tabell och primärnyckeln. (Detta kan fungera som en primärnyckel eftersom inga två konton i vårt system ska vara associerade med flera konton för samma externa tjänst.)
Den andra kolumnen kommer att vara id för det externa kontot – facebook_id , till exempel. Det finns en unik begränsning på var och en av facebook_id , google_id och twitter_id kolumner. Vi vet att inga två konton får samma id. Faktum är att när användaren är autentiserad med en extern tjänst känner vi till deras facebook_id . När vi hittar motsvarande rad i facebook_account tabell och hitta rätt user_profile , vi vet vilken användare som just loggat in i systemet. Om det inte finns någon rad med detta id skapar vi en ny rad i user_profile tabell och en ny rad i lämplig kontotabell.
Här är den slutliga modellen: