Indtastning af brugernavn og adgangskode er en måde at få adgang til en konto på, men det er ikke den eneste. I denne artikel vil vi se, hvordan du aktiverer eksterne tjenester (som Google eller Facebook), når du logger ind på en database.
Hvad er logins til eksterne tjenester?
At give en bruger mulighed for at få adgang til deres systemkonti gennem eksterne tjenester er en voksende tendens blandt webdesignere. Denne mulighed kan give flere fordele, såsom at give brugerne én mindre kombination af navn og adgangskode at huske. Det kan også hjælpe administratorer med at tilpasse brugeroplevelser.
Når webapplikationer tilbyder et eksternt service-login, ser login-skærmen ud som på billedet nedenfor. En bruger kan indtaste deres login og adgangskode, eller de kan klikke på en knap, som vil omdirigere dem til den tjeneste, de selv vælger (Facebook, Twitter, Google osv.), hvor de vil logge ind og blive omdirigeret til den originale applikation.
Her er et eksempel på login-skærmbilledet fra Vertabelo Academy:
Sådan fungerer eksterne logins
Tilføjelse af eksterne login-tjenester kræver noget ekstra arbejde fra udviklerne. De fleste populære sociale medietjenester bruger en protokol kaldet OAuth 2.0 . Kun Twitter bruger en ældre protokol kaldet OAuth 1.0 . Protokollen gør det muligt at læse brugeroplysninger som deres fulde navn, e-mail, køn osv. De nøjagtige tilgængelige oplysninger afhænger af den sociale medietjeneste og hvad end brugeren har givet. (Det er f.eks. muligt at have en Facebook-konto uden en tilknyttet e-mailadresse.) Uanset hvad vil vi dog fokusere på, hvordan man implementerer dette system i designet af en database.
Som udgangspunkt vil vi bruge vores tidligere artikel om adgangskodegendannelse og e-mailbekræftelse som udgangspunkt. Her er de brugerrelaterede tabeller fra denne artikel.
Design af en database til eksterne logins
Mange oplysninger i user_account tabellen er relateret til håndtering af godkendelse – plus relaterede funktioner som påmindelse om adgangskode og e-mail-bekræftelse – på egen hånd. Vi har ikke brug for disse kolonner, hvis brugeren godkender med en ekstern tjeneste. Adgangskodepåmindelsen, e-mailbekræftelsen og andre funktioner håndteres af den eksterne tjeneste. Det første trin i vores design er at adskille user_account tabel i to tabeller:user_account og user_profile .
user_account table håndterer nu hele sin egen autentificeringsbogføring. user_profile tabel repræsenterer de faktiske brugeroplysninger:navn, e-mail, tidszone, accept af servicevilkår og så videre. Alle virksomhedstabeller skulle nu være relateret til user_profile tabel.
Nu til de eksterne konti. OAuth protokol giver os i sidste ende en identifikator for brugeren i deres system. Denne identifikator er ikke brugerens navn i det eksterne system. Det er blot en identifikator for vores applikation. Vi skal gemme dette interne id i vores database. Vi kunne tilføje nullbare kolonner facebook_id , google_id , twitter_id osv. til tabellen user_profile . Men vi vil gøre noget andet.
Vi tilføjer nye tabeller:facebook_account , twitter_account , google_account , som gemmer det eksterne id. På denne måde, hvis vi har brug for det, kan vi tilføje yderligere oplysninger specifikt for hver social hjemmeside. Hvis vi vil tilføje en login-mulighed til et andet socialt websted, behøver vi ikke ændre user_profile bord. Vi tilføjer kun endnu en external_service_account tabel.
Hver af de nye tabeller deler det samme kolonneformat. En af dem vil være int user_profile_id , som både er en fremmednøgle, der refererer til id-kolonnen i user_profile tabel og den primære nøgle. (Dette kan fungere som en primær nøgle, fordi ikke to konti i vores system bør være knyttet til flere konti for den samme eksterne tjeneste.)
Den anden kolonne vil være id'et for den eksterne konto – facebook_id , for eksempel. Der er en unik begrænsning på hver af facebook_id , google_id , og twitter_id kolonner. Vi ved, at ikke to konti får samme id. Faktisk, når brugeren er autentificeret med en ekstern tjeneste, kender vi deres facebook_id . Når vi finder den tilsvarende række i facebook_account tabel og find den rigtige user_profile , ved vi, hvilken bruger der lige er logget ind på systemet. Hvis der ikke er nogen række med dette id, opretter vi en ny række i user_profile tabel og en ny række i den relevante kontotabel.
Her er den endelige model: