Mevcut kullanıcı veritabanınızı Logto'ya taşıma hakkında genel bir kılavuz

Logto'nun henüz bir veri taşıma için bir dizi araca sahip olmadığı, ancak Yönetim API'nin temel yeteneklerini açtığını belirtelim. Bu, kullanıcıların mevcut kullanıcı veritabanlarının taşınmasını tamamlamalarına engel olmayacak.

Topluluk kullanıcılarından alınan bazı ihtiyaçlara göre ve şu anda kullanıcı veritabanı taşıma adımlarını açıklayan bir belgemenin olmaması nedeniyle, kullanıcıların belirli fikirler bulması ve Logto kodu ve belgelemesini okuma süresini tasarruf etmeleri için bu makalede uygun bir giriş yapıyoruz.

Adım 1: Logto'nun temel kullanıcı veri yapısını ve kullanım durumunu anlayın#

Logto, altında PostgreSQL veritabanını kullanır. Çeşitli performans avantajlarına ek olarak, önemli bir neden, özel JSON / JSONB veri türünü destekler olması ve JSON türündeki verilerin iç değerlerinde index oluşturmaya izin vermesi, böylece hem veritabanı performansını hem de genişletilebilirliği dengeler.

Logto'nun kullanıcı veri yapısı hakkında bilgi almak için lütfen kullanıcı referansına başvurun. Burada Logto'nun diğer kimlik hizmetlerinden farklı olabileceği bazı yönleri tanımlama konusuna odaklanacağız.

id#

Bu, Logto kullanıcıları için rastgele oluşturulmuş benzersiz bir iç kimlik belirleyicisidir. Kullanıcılar, Logto tabanlı hizmetleri kullanırken 'id' bilincinde olmazlar.

Veritabanlarıyla aşina olan mühendisler, bunu garip bulmamalıdır. En temel kimlik sistemlerinin bile kullanıcıları benzersiz olarak tanımlamak için bir 'id'ye sahip olacakları, ancak formlarının genellikle farklı olacağıdır. Bazı kimlik hizmetleri, kullanıcıları benzersiz olarak tanımlamak için kullanıcı adını kullanabilir.

username, primaryEmail, primaryPhone#

Burada, kullanıcı adı, birincil e-posta ve birincil telefon, Logto'nun diğer kimlik sistemlerinden büyük ölçüde farklıdır - bunların hepsi son kullanıcı tarafından algılanabilen benzersiz belirleyiciler olarak hizmet edebilir.

Birçok diğer kimlik sistemlerinde, kimlik doğrulama için kullanıcı adı kullanılır (kullanıcı adları hesaplar arasında çoğaltılamaz), bu kolayca anlaşılır.

Ancak Logto'da, birincil e-posta ve telefon da kullanıcıları ayırmak için kullanılır. Yani, eğer bir kullanıcı A zaten [email protected] birincil e-postaya sahipse, diğer kullanıcılar B bu e-posta adresini kendi birincil e-postaları olarak ekleyemez. Birincil telefon benzer şekilde çalışır.

Diğer kimlik sistemlerine göre, aynı e-posta/telefonla birden fazla hesap kaydı yapılabiliyorken Logto'da buna izin verilmez(Logto’nun 'customData'sına e-postalar ve telefonlar eklenebilir). Bunun sebebi, Logto'daki birincil e-posta ve telefon, parolasız oturum açma işlemini yapabilme yeteneğine sahip olmasıdır.

identities#

Logto, bu 'identities' alanını JSON-tipinde tanımlar, tip tanımı:

Son yıllarda, yeni kullanıcıları elde etmeyi kolaylaştırmak için, kimlik sistemleri kullanıcıların 'google' / 'facebook' gibi bazı mevcut sosyal hesaplarla hızlıca oturum açabilmelerine izin verir.

Aşağıdaki örnekte, 'identities' alanı sosyal giriş bilgilerini saklar:

Facebook ve github, sosyal sağlayıcıların adlarıdır, 'userId' oturum açma için kullanıcının sosyal hesabının 'id'sidir. 'details', kullanıcının sosyal sağlayıcıya görüntülemek üzere yetkilendirdiği bazı diğer bilgileri de içerir, bu bilgiler belirli zamanlarda kullanıcının Logto kullanıcı profiline eklenecektir.

Eğer önceki veritabanı, kullanıcının kullandığı sosyal sağlayıcının adını (örn. 'facebook' , 'google') ve 'id'sini içeriyorsa(önceki örnekte 'userId'yi görün), o zaman Logto kullanıcısı aynı sosyal hesapla doğrudan oturum açabilir.

customData#

Bu alan, parolasız oturum açma için kullanılamayan yukarıda belirtilen e-postaları/telefonları (bildirimleri almak veya diğer işle ilgili işlevler için kullanılabilir) gibi herhangi bir kullanıcı ile ilgili bilgileri depolayabilir, vb

Diğer alanlar oldukça anlaşılır (daha sonra açıklanacak olan 'passwordEncrypted' ve 'passwordEncryptionMethod' dışında), lütfen belgeleri kendiniz okuyun.

Adım 2: Veritabanı taşıma betikleri yazma#

Büyük ölçekli veritabanı taşıma için, taşıma betikleri yazmak en yaygın yöntemdir. Farklı ihtiyaçları karşılamak için taşıma betiklerinin nasıl yazılacağını anlamadı düşündürmek için basit bir örnek sağlayacağız.

Taşıma betikleri yazarken, orijinal verilerin alınma sürecini atlıyoruz, çünkü verileri almanın birçok yolu vardır, örneğin veritabanından dosyalara verilerin dışa aktarılması ve sonra dosyaların okunması ya da API'ler aracılığıyla verilerin alınması. Bunlar, taşıma betiğinin odak noktası olmadığından, burada ayrıntılı olarak tartışılmayacaklardır.

Taşıma betiği boyunca 'tenant_id'yi gördüğünüzde, bu size garip gelebilir. Logto, çok kiracılı bir mimariye dayanmaktadır. Açık kaynaklı Logto (Logto OSS) kullanıcıları için, kullanıcının 'tenant_id'sini 'default' olarak ayarlayabilirsiniz.

Kendi kendine konaklama yapan Logto OSS kullanıcıları için, veritabanı bağlantısını elde etmek kolaydır. Ancak, Logto bulut kullanıcıları için, güvenlik nedenleriyle, şu anda kullanıcılara veritabanı bağlantı izinlerini sağlayamayız. Kullanıcıların, API Dokümantasyonuna başvurması ve kullanıcıları taşımak için Kullanıcı ile ilgili API'ları kullanması gerekmektedir. Bu yöntemin büyük ölçekli kullanıcı veri taşıma işlemi için uygun olmadığını, ancak bu aşamada sınırlı sayıda kullanıcının taşınmasını hala halledebileceğimizi anlıyoruz.

Adım 3: Hashlenen parola taşıma zorluğu ve potansiyel yol açma#

Daha önceki bir blog yazımızda parola saldırılarına karşı alınabilecek bazı önlemlerden bahsettik. Kimlik altyapısı sağlayıcıların yapabileceği bir şey, parolaları düz metin olarak saklamamak, ancak hashlenmiş parolaları saklamaktır.

Başka bir blog yayınında, parola hash'lerini açıkladık, orada hash değerlerinin geri döndürülemez olduğunu belirttik.

İkinci blog yazısında ayrıca bazı hashleme algoritmalarının evrimini karşılaştırdık. Logto kendisi, makalede bahsedilen Argon2i algoritmasını kullanır ve şimdilik diğer hash algoritmalarını desteklemiyor. Bu, diğer hashleme algoritmalarını kullanan eski kullanıcı veritabanlarının parola hash'leri, Logto'nun veritabanlarına doğrudan taşınamaz anlamına gelir.

Logto, Argon2i'ye ek olarak diğer yaygın kullanılan hash algoritmalarını destekler hale gelirse bile, hash algoritmaları uygulandığında tuzun esnekliği nedeniyle eski verilerin doğrudan taşınması hala zor olacaktır.

Gelecekte diğer hash algoritmalarını desteklemenin yanı sıra, Logto muhtemelen çeşitli durumlara uyarlamak için özel tuz hesaplama yöntemleri sağlayacaktır.

Bundan önce, Logto'nun oturum açma deneyimi ayarına başvurabilirsiniz, böylece kullanıcıların diğer yollarla (örneğin e-posta + doğrulama kodu gibi) oturum açmalarını sağlar, uygulamaya girmeden önce yeni bir parola girebilirler(Argon2i hashleme algoritması kullanacak). Sonra yeni parola daha sonra oturum açmak için kullanılabilir.

Dikkate alınmalıdır ki, orijinal kullanıcı verisi yalnızca parola ile oturum açmayı destekliyorsa, yukarıda bahsedilen yol açma metodu bu durum için çalışmayacaktır. Bu, yukarıda belirtilen yol açma işlemi, aslında parola hash uyumsuzluğu sorununu, alternatif oturum açma yöntemleri kullanarak ve Logto'nun son kullanıcı akışındaki 'gerekli bilgi tamamlama' mekanizmasından yararlanarak çözer.

Dolayısıyla, orijinal kullanıcı verileri yalnızca parola oturumu açmayı desteklerse, yol açma işlemi bu durumu çözemez çünkü alternatif oturum açma seçenekleri yoktur.

Burada belirtilen yol açma işlemi, aslında haslenmiş parola taşıma sorununu gerçekten çözmez, ancak Logto ürün perspektifinden alternatif bir çözüm sağlar, böylece kullanıcıların ürününüze oturum açmasını engellemez.

Adım 4: Logto'ya kademeli geçiş ve durum izlemesi#

Yukarıdaki tüm adımları tamamladıktan sonra, son kullanıcılar artık hizmetinizi Logto aracılığıyla kullanıp kullanamadıklarını kontrol edebilir.

Hizmet genellikle taşıma sırasında kesilmediği için, Logto'ya senkronize edilen kullanıcı verilerinin güncel olmadığı olasıdır. Bu tür yaygın olmayan durumlar tespit edildiğinde, eski veritabanından Logto'ya senkronizasyon gerçekleştirilmelidir.

Daha uzun bir süre boyunca (veya diğer tanımlanmış metrik de uygulanabilir) tutarsız verilerin meydana gelmemesi durumunda, eski veritabanı tamamen terk edilebilir.

Sonuç#

Yazıda, ideal bir veritabanı taşıma işleminin izlemesi gereken adımları tanıttık.

Yukarıda bahsedilmeyen sorunlarla karşılaşırsanız, topluluğumuza katılmaktan ya da bize yardım için başvurmaktan çekinmeyin. Karşılaştığınız sorunlar, diğerleri tarafından da karşılaşılan sorunlar olabilir ve gelecekte taşıma araçlarını tasarlamamız gereken konular olacaktır.