Het invoeren van een gebruikersnaam en wachtwoord is een manier om toegang te krijgen tot een account, maar het is niet de enige. In dit artikel zullen we zien hoe u externe services (zoals Google of Facebook) kunt inschakelen wanneer u zich aanmeldt bij een database.
Wat zijn aanmeldingen voor externe services?
Een gebruiker de mogelijkheid geven om via externe services toegang te krijgen tot zijn systeemaccounts is een groeiende trend onder webontwerpers. Deze optie kan verschillende voordelen bieden, zoals gebruikers één naam-en-wachtwoordcombinatie minder om te onthouden. Het kan beheerders ook helpen om gebruikerservaringen te personaliseren.
Wanneer webapplicaties een externe service-login aanbieden, ziet het inlogscherm eruit als de onderstaande afbeelding. Een gebruiker kan zijn login en wachtwoord invoeren, of hij kan op een knop klikken die hem doorverwijst naar de dienst van zijn keuze (Facebook, Twitter, Google, enz.) waar hij zal inloggen en wordt doorgestuurd naar de oorspronkelijke applicatie.
Hier is een voorbeeld van een inlogscherm van de Vertabelo Academy:
Hoe externe aanmeldingen werken
Het toevoegen van externe inlogdiensten vereist wat extra werk van de ontwikkelaars. De meeste populaire sociale-mediadiensten gebruiken een protocol genaamd OAuth 2.0 . Alleen Twitter gebruikt een ouder protocol genaamd OAuth 1.0 . Het protocol maakt het lezen van gebruikersinformatie mogelijk, zoals hun volledige naam, e-mail, geslacht, enz. De exacte beschikbare informatie hangt af van de socialemediaservice en wat de gebruiker ook heeft verstrekt. (Het is bijvoorbeeld mogelijk om een Facebook-account te hebben zonder een bijgevoegd e-mailadres.) Hoe dan ook, we zullen ons concentreren op hoe dit systeem te implementeren in het ontwerp van een database.
Als uitgangspunt gebruiken we ons vorige artikel over wachtwoordherstel en e-mailbevestiging als basis. Dit zijn de gebruikersgerelateerde tabellen uit dit artikel.
Een database ontwerpen voor externe aanmeldingen
Veel informatie in het user_account tabel is gerelateerd aan het zelf afhandelen van authenticatie - plus gerelateerde functies zoals wachtwoordherinnering en e-mailbevestiging. We hebben deze kolommen niet nodig als de gebruiker verifieert met een externe service. De wachtwoordherinnering, e-mailbevestiging en andere functies worden afgehandeld door de externe service. De eerste stap in ons ontwerp is het scheiden van het user_account tabel in twee tabellen:user_account en user_profile .
Het user_account table regelt nu al zijn eigen authenticatieboekhouding. Het user_profile tabel geeft de feitelijke gebruikersinformatie weer:naam, e-mail, tijdzone, acceptatievoorwaarden van de service, enzovoort. Alle zakelijke tabellen zouden nu gerelateerd moeten zijn aan het user_profile tafel.
Nu naar de externe rekeningen. De OAuth protocol geeft ons uiteindelijk een identificatie voor de gebruiker in hun systeem. Deze identifier is niet de gebruikersnaam in het externe systeem. Het is slechts een identificatie voor onze applicatie. We moeten deze interne id opslaan in onze database. We kunnen nullable kolommen toevoegen facebook_id , google_id , twitter_id , etc. naar de tabel user_profile . Maar we zullen iets anders doen.
We zullen nieuwe tabellen toevoegen:facebook_account , twitter_account , google_account , die de externe id opslaat. Op deze manier kunnen we, indien nodig, aanvullende informatie toevoegen specifiek voor elke sociale website. Als we een inlogmogelijkheid voor een andere sociale website willen toevoegen, hoeven we het user_profile tafel. We voegen alleen nog een external_service_account tafel.
Elk van de nieuwe tabellen heeft hetzelfde kolomformaat. Een daarvan is int user_profile_id , wat zowel een externe sleutel is die verwijst naar de id-kolom in de user_profile tabel en de primaire sleutel. (Dit kan als primaire sleutel dienen omdat er geen twee accounts in ons systeem aan meerdere accounts van dezelfde externe service mogen worden gekoppeld.)
De andere kolom is de id van het externe account – facebook_id , bijvoorbeeld. Er is een unieke beperking voor elk van de facebook_id , google_id , en twitter_id kolommen. We weten dat geen twee accounts dezelfde id krijgen. Als de gebruiker is geverifieerd met een externe service, kennen we zijn facebook_id . Wanneer we de overeenkomstige rij vinden in het facebook_account tabel en zoek de juiste user_profile , weten we welke gebruiker zojuist op het systeem is ingelogd. Als er geen rij is met deze id, maken we een nieuwe rij aan in het user_profile tabel en een nieuwe rij in de juiste rekeningtabel.
Hier is het definitieve model: