Yleinen ohjeistus olemassa olevan käyttäjätietokannan siirtämiseksi Logtoon
Tässä artikkelissa esitellään, kuinka hyödyntää olemassa olevia työkaluja aikaisemman käyttäjädatan siirtämiseksi Logtoon, tilanteessa jossa Logto ei ole vielä tarjonnut datan siirtopalveluita.
Logtolla ei ole vielä työkalusarjoja datan siirtoon, mutta olemme avanneet hallinta-API:n perusominaisuuksia. Tämä ei estä käyttäjiä täydentämästä olemassa olevien käyttäjätietokantojen siirtoa kirjoittamalla skriptejä.
Joidenkin yhteisökäyttäjiltä saatujen tarpeiden vuoksi, ja koska meillä ei tällä hetkellä ole dokumentaatiota, joka selittää käyttäjätietokannan siirron erityiset vaiheet, teemme tässä artikkelissa asianmukaisen johdannon auttaaksemme käyttäjiä löytämään erityisiä ideoita ja säästämään aikaa Logton koodin ja dokumentaation lukemisessa.
Vaihe 1: Ymmärrä Logton perustietorakenne ja käyttötapaus#
Logto käyttää PostgreSQL-tietokantaa taustallaan. Sen eri suorituskykyetujen lisäksi tärkeä syy on, että se tukee mukautettuja JSON/JSONB-datatyyppiä ja mahdollistaa indeksoinnin rakentamisen JSON-tyyppisten datojen sisäisten arvojen perusteella, mikä tasapainottaa sekä tietokannan suorituskyvyn että laajennettavuuden.
Logton käyttäjädatarakenteeseen liittyen, katso käyttäjäviite saadaksesi tarkempia tietoja. Tässä keskitymme kuvaamaan joitakin ilmiöitä, joissa Logto saattaa erota muista identiteettipalveluista.
Tämä on satunnaisesti luotu sisäinen yksilöllinen tunniste Logton käyttäjille. Käyttäjät eivät ole tietoisia id:stä käyttäessään Logtoon perustuvia palveluita.
Tietokantateknologiaa tuntevista insinööreistä tämä ei ole outoa. Jopa kaikkein alkeellisimmilla identiteettijärjestelmillä on id, jolla käyttäjät voidaan yksilöllisesti tunnistaa, vaikka niiden muodot usein eroavat. Joillakin identiteettipalveluilla saattaa olla käyttäjänimiä käyttäjien yksilölliseen tunnistamiseen.
Tässä kohdassa käyttäjänimi, ensisijainen sähköposti ja ensisijainen puhelin ovat kohtia, joissa Logto eroaa huomattavasti muista identiteettijärjestelmistä - ne voivat kaikki toimia loppukäyttäjän havaitsemina yksilöllisinä tunnisteina.
Monissa muissa identiteettijärjestelmissä käyttäjänimeä käytetään tunnistamiseen (käyttäjänimet eivät voi olla päällekkäisiä eri tileillä), mikä on helppo ymmärtää.
Mutta Logtossa ensisijaisia sähköpostia/puhelinta käytetään myös käyttäjien erottamiseen. Toisin sanoen, jos käyttäjä A:lla on jo ensisijaisena sähköpostina [email protected], muut käyttäjät B eivät voi lisätä tätä sähköpostiosoitetta ensisijaiseksi sähköpostikseen. Ensisijaisen puhelimen osalta toimii samankaltaisesti.
Joissakin muissa identiteettijärjestelmissä voidaan rekisteröidä useita tilejä eri käyttäjänimillä, mutta sitoa sama sähköposti/puhelin, mikä ei ole sallittua Logtossa (sähköposteja/puhelimia voidaan lisätä Logton customData:an). Tämä johtuu siitä, että Logtossa ensisijaisia sähköpostia/puhelinta voidaan käyttää salasanattomaan kirjautumiseen.
Logto määrittelee tämän identities-kentän JSON-tyyppisenä, sen tyyppimääritelmä:
Viime vuosina, helpottaakseen uusien käyttäjien saantia, identiteettijärjestelmät mahdollistavat käyttäjien kirjautumisen nopeasti joillakin olemassa olevilla sosiaalisilla tileillä, joilla on suuri käyttäjäkunta, kuten google / facebook, jne.
Esimerkissä alla, identities-kenttä tallentaa sosiaaliseen kirjautumiseen liittyviä tietoja:
Missä facebook ja github ovat sosiaalisten tarjoajien nimiä, userId on käyttäjän sosiaalitilin id, jota käytetään kirjautumiseen. details sisältää myös muuta tietoa, joka käyttäjän on valtuutettu sosiaalisen tarjoajan näyttämään ja joka lisätään käyttäjän Logton käyttäjäprofiiliin tietyissä tilanteissa.
Jos aiemmassa tietokannassa on käyttäjän käyttämän sosiaalisen tarjoajan nimi (esim. facebook , google) ja id (katso edellinen esimerkki userId), käyttäjä voi Logtossa kirjautua suoraan samalla sosiaalitilillä.
Tämä kenttä voi tallentaa mitä tahansa käyttäjään liittyvää tietoa, kuten yllä mainittuja sähköpostiosoitteita/puhelimia, joita ei voida käyttää salasanattomaan kirjautumiseen (saatetaan käyttää ilmoitusten vastaanottamiseen tai muihin liiketoimintaan liittyviin toimintoihin), jne.
Muut kentät ovat suhteellisen helppoja ymmärtää (lukuun ottamatta passwordEncrypted ja passwordEncryptionMethod, jotka selitetään myöhemmin), lue dokumentaatio itse.
Vaihe 2: Tietokannan siirtoskriptien kirjoittaminen#
Laajamittaisessa tietokannan siirrossa siirtoskriptien kirjoittaminen on yleisin lähestymistapa. Annamme yksinkertaisen esimerkin, joka auttaa ymmärtämään, miten kirjoittaa siirtoskriptejä eri tarpeisiin.
On huomattava, että siirtoskriptejä kirjoittaessa ohitamme alkuperäisen datan noutoprosessin, koska on monia tapoja saada data, kuten tietokannasta exporttaus tiedostoihin ja sitten tiedostojen lukeminen, tai noutaminen API:en kautta. Nämä eivät ole siirtoskriptin keskipisteenä, joten emme puutu niihin tässä tarkemmin.
Kun näet tenant_id siirtoskriptissä, voit pitää sitä oudoksi. Logto perustuu monivuokralaiseen arkkitehtuuriin. Avoimen lähdekoodin Logton (Logto OSS) käyttäjille voit vain asettaa käyttäjän tenant_id:ksi default.
Omakustannehallituista Logto OSS -käyttäjistä tietokantayhteys on helppo hankkia. Kuitenkin Logto-pilvikäyttäjille, turvallisuussyistä, emme tällä hetkellä voi antaa tietokantayhteyslupia käyttäjille. Käyttäjien on viitattava API-dokumentaatioon ja käytettävä käyttäjiin liittyviä API:toja käyttäjien siirtämiseen. Ymmärrämme, että tämä menetelmä ei sovellu laajamittaiseen käyttäjädatan siirtoon, mutta voi silti käsitellä rajallisen määrän käyttäjien siirtoa tässä vaiheessa.
Vaihe 3: Salatun salasanan siirron haaste ja mahdollinen kiertotapa#
Aiemmassa blogiartikkelissamme puhuimme joistakin toimenpiteistä estääksemme salasanahyökkäyksiä. Yksi asia, jonka identiteetti-infrastruktuuripalveluntarjoajat voivat tehdä, on olla tallentamatta salasanoja selväkielisinä vaan tallentaakseen ne hashattuina salasanoina.
Toinen blogipostaus selitti salasanahashit, jossa totesimme, että hash-arvot ovat peruuttamattomia.
Tässä toisessa blogipostauksessa vertailtiin myös joidenkin hajautusalgoritmien kehitystä. Logto itse käyttää artikkelissa mainittua Argon2i-algoritmia eikä tue muita hajautusalgoritmeja tällä hetkellä. Tämä tarkoittaa, että vanhan käyttäjätietokannan hajautetut salasanat, jotka käyttävät muita hajautusalgoritmeja, eivät voi siirtyä suoraan Logton tietokantaan.
Vaikka Logto tukisi muita yleisesti käytettyjä hajautusalgoritmeja Argon2i:n lisäksi, olisi edelleen vaikeaa siirtää vanhaa dataa suoraan, koska suolan joustavuus sovellettaessa hajautusalgoritmeja.
Lisäksi tukemaan muita hajautusalgoritmeja tulevaisuudessa, Logto on luultavasti mahdollista tarjota mukautettuja suolalaskentamenetelmiä sopeutumaan erilaisiin tilanteisiin.
Sitä ennen voit käyttää Logton kirjautumiskokemuksen konfiguraatiota salliaksesi käyttäjien kirjautua muilla tavoilla (kuten sähköposti + vahvistuskoodi) ja syöttää uuden salasanan (joka käyttää Argon2i-hajautusalgoritmia) ennen kuin menevät sovellukseen. Sitten uutta salasanaa voidaan käyttää kirjautumiseen myöhemmin.
On huomattava, että jos alkuperäinen käyttäjädata tukee vain kirjautumista salasanalla, edellä mainittu kiertotapa ei toimi tässä tilanteessa. Tämä johtuu siitä, että aiemmin mainittu kiertotapa itse asiassa ratkaisee salasanahashin yhteensopimattomuusongelman käyttämällä vaihtoehtoisia kirjautumismenetelmiä ja hyödyntämällä "vaaditun tiedon täyttö" -mekanismia Logton loppukäyttäjäprosessissa.
Joten jos alkuperäinen käyttäjädata tukee vain salasanakirjautumista, kiertotapa ei pysty ratkaisemaan tätä tilannetta, koska muita kirjautumisvaihtoehtoja ei ole saatavilla.
_Tässä mainittu kiertotapa ei oikeasti ratkaise hajautetun salasanan siirron ongelmaa, mutta tarjoaa vaihtoehtoisen ratkaisun Logton tuotteen näkökulmasta välttääkseen estämästä käyttäjiä kirjautumasta tuotteeseesi.
Vaihe 4: Vähittäinen siirtyminen Logtoon ja tilan seuranta#
Suoritettuasi edellä mainitut vaiheet, loppukäyttäjät voivat jo kirjautua sisään ja käyttää palveluasi Logton kautta.
Koska palvelua ei yleensä katkaista siirron aikana, on mahdollista, että Logtoon synkronoitu käyttäjädata ei ole ajan tasalla. Kun tällaisia harvinaisia tapauksia havaitaan, synkronointi vanhasta tietokannasta Logtoon on suoritettava.
Pidemmän ajan kuluttua (tai muita määriteltyjä mittareita voidaan soveltaa) ilman ristiriitaisten tietojen esiintymistä, vanha tietokanta voidaan kokonaan hylätä.
Julkaisussa esittelimme vaiheet, joita ihanteellisen tietokannan siirron tulee käydä läpi.
Jos kohtaat ongelmia, joita ei mainittu yllä, älä epäröi liittyä yhteisöömme tai ottaa meihin yhteyttä saadaksesi apua. Ongelmia, joita kohtaat, voivat kohdata myös muut, ja ne tulevat olemaan asioita, joita meidän tulee harkita suunnitellessamme tulevia siirtoalan työkaluja.
