Derinlemesine yazılım eğitimleri için kanalımı takip edebilirsiniz...

Asp.NET Core Identity – Veritabanı Tablolarını İnceleyelim – III

Merhaba,

Bir önceki Asp.NET Core Identity – Identity Altyapısı Kurulumu – II başlıklı makalede Asp.NET Core uygulamalarında Identity altyapısının nasıl kurulduğunu incelemiştik. Bu inceleme neticesinde migrate edilerek oluşturulan veritabanı içerisinde aşağıdaki tablolar oluşturulmuştur. İşte bu makalemizde bu tabloların ne olduğunu, hangi işlev için üretildiklerini detaylıca irdeleyeceğiz.

Asp.NET Core Identity – Alt Yapı Kurulumu - II

AspNetUsers İnceleme
Asp.NET Core Identity – Veritabanı Tablolarını İnceleyelim - III
Ne işe yarar?
Kullanıcılarla ilgili genel geçer bilgileri tutan tablodur.
1. Her bir kullanıcıyı temsil edecek olan Primary Key Id değeri. Dikkat edilirse nvarchar olarak ayarlanmıştır. Bu ayarlamanın nasıl yapıldığını bir sonraki makalemizde ele alacağız…
2. Kullanıcı adını tutan kolondur. Dikkat edilirse “UserName” kolonunun hemen altında “NormalizedUserName” kolonuda mevcuttur. Neden böyle bir kolona ihtiyaç duyulmuştur? Milyonluk/milyarlık verilerde(Big Data) arama sorguları gerçekleştirilirken hız kazanmak için oluşturulmuş kolondur. Big datanın söz konusu olduğu durumlarda bir arama sorgusu “UserName” üzerinde değil “NormalizedUserName” kolonu üzerinde gerçekleştirilir. Çünkü “Normalized…” ile başlayan kolonlar indekslenmiştir. Dolayısıyla sorgularda daha hızlı çalışan bir altyapıya sahiptirler. “Normalized…” kolonlarının bir diğer özelliği tek bir formatta veri tutmasıdır. Örneğin; “UserName” kolonunda bulunan “Gençay” değeri aynen “NormalizedUserName” kolonuna “GENÇAY” olarak büyük harflerle kopyalanacaktır. Büyük harflerle girilmesinin sebebi tek bir fortmat olmasının getirisi olan daha hızlı eşleştirme yapılabilir olmasıyla birlikte daha hızlı indexlenebilir olmasıdır. Bir kolonun “Normalized…” versiyonu varsa eğer o kolonun kendisi indexlenmemektedir. Dolayısıyla asıl hızlı sorgulamalar Entity Framework tarafından Identity’e özel “Normalized…” kolonlarına odaklanılarak gerçekleştirilir. Bir önceki Identity sürümünde tüm indexlemeler direkt olarak ilgili kolon üzerinde gerçekleştiriliyordu. Dolayısıyla “Normalized…” ile başlayan kolonlar söz konusu değildi. Bunun getirisinin yanında birçokolası hataların yaşanması maliyeti oldukça yükseltiyordu.
3. Kullanıcının e-posta bilgisini tutan alandır. 2. numaralı kolonda olduğu gibi bu kolonunda aynı amaca hizmet eden indexlenmiş değeri olan “NormalizedEmail” kolonu mevcuttur.
4. Kullanıcıdan alınan tüm passwordler Hash algoritmasıyla şifrelenerek tutulmaktadır.
5. Kullanıcı ilk oluşturulduğunda(create) buraya bir build değeri atanır. Sonraki her güncelleme üzerine bu değer güncellenecektir. Dolayısıyla bizlerde bu kullanıcı üzerinde bir değişiklik olduğuna dair bilgi edinmiş olacağız. Bir nevi Data Concurrency sağlayabilmek için oluşturulmuştur.
6. İlgili veri üzerinde Data Concurrency sağlayabilmek için oluşturulmuştur.
7. Kullanıcının kaydı neticesinde aktivasyon yapılanmasının iki adımlı olup olmadığına dair kayıt tutar. Bu kolon genellikle 3. party üyelik sistemleriyle birlikte kullanılır. Örneğin; kullanıcı Facebook üzerinden giriş yaptığında ekstradan telefon ile onay gerektiriyorsa işte “TwoFactorEnabled” kolonu true/1 olarak işaretlenecektir.
8. Kullanıcı girişlerine dair yapılan hataları ve engel durumunu tutan kolonlardır. “LockoutEnd” kolonu kaç kez yanlış girildiğine dair, “LockoutEnabled” kolonu kullanıcının aktifliğine dair ve “AccessFailedCount” kolonu ise kaç başarısız giriş yapılmaya çalışıldığına dair bilgi tutmaktadır. Identity mimarisi bu yapıları otomatik işleyecektir. Dolayısıyla tarafımızca custom bir kod geliştirmemize lüzum görülmemektedir.
AspNetRoles İnceleme
Asp.NET Core Identity – Veritabanı Tablolarını İnceleyelim - III
Ne işe yarar?
Uygulamada kullanıcılara özgü tanımlanan rolleri tutan tablodur. Şöyle tabloyu incelersek rollerin adını tutacak olan “Name” kolonu ve bu değerleri indexleyip big data durumlarında performans kazandıracak indexlenmiş “NormalizedName” kolonu mevcuttur. Ayriyetten veri tutarlılığı için de “ConcurrencyStamp” kolonu mevcuttur.
AspNetUserRoles İnceleme
Asp.NET Core Identity – Veritabanı Tablolarını İnceleyelim - III
Ne işe yarar?
Uygulamada hangi kullanıcı hangi rol yetkilerine sahip ilişkilendiren Cross Table(Ara Tablo) görevi gören bir tablodur. Composite primary key olarak ayarlanan “UserId” ile “RoleId” kolonları üzerinden bu ilişki sağlanmaktadır.
AspNetUserClaims İnceleme
Asp.NET Core Identity – Veritabanı Tablolarını İnceleyelim - III
Ne işe yarar?
Kullanıcılara dair ekstra bilgiler bu tabloda tutulmaktadır.
AspNetRoleClaims İnceleme
Asp.NET Core Identity – Veritabanı Tablolarını İnceleyelim - III
Ne işe yarar?
Uygulamada tanımlanan rollere dair ekstra bilgiler bu tabloda tutulmaktadır.
AspNetUserLogins İnceleme
Asp.NET Core Identity – Veritabanı Tablolarını İnceleyelim - III
Ne işe yarar?
3. party üyelik sistemlerinde diğer platformdaki kullanıcıya ait id değerini bu tabloda tutmaktadır. Bu tablo otomatik olarak Identity mimarisi tarafından işlenmektedir.
AspNetUserTokens İnceleme
Asp.NET Core Identity – Veritabanı Tablolarını İnceleyelim - III
Ne işe yarar?
Token bazlı doğrulamalarda üretilen token değeri bu tabloda tutulur.

Evet… Artık üretilen tablolarımızı da tanıdığımıza göre bir sonraki içeriğimizde “IdentityUser” sınıfından türeyen sınıflara custom property eklenince nasıl bir inşa söz konusu olduğunu inceleyebiliriz. O halde şimdilik görüşmek üzere…

İlgilenenlerin faydalanması dileğiyle…
İyi çalışmalar…

Bunlar da hoşunuza gidebilir...

7 Cevaplar

  1. Emre Sekeroglu dedi ki:

    Değerli paylaşımlarınız için teşekkür ederim. Identity işlemlerinde yaşadığım bir sorun hakkında desteğinize ihtiyacım var.

    Custom olarak AppRole sınıfı oluşturdum ve Role kaydı yapıyorum. Id değerlerimi int tipinde belirledim.
    Rolü kaydediyorum fakat NormalizedName alanı null olarak kayda geçiyor otomatik olarak büyük harfle kayda almıyor.
    Bunu doğru bir şekilde yapmanın bir yolu var mıdır?
    Not: id alanlarını string olarak kullandığımda otomatik büyük harfle gerçekleşiyor kayıt.

    • Gençay dedi ki:

      Merhaba,

      Esasında yazı dizimizde a’dan z’ye herşeyin nasıl doğru bir şekilde icra edildiğini ele almış bulunmaktayız. Lakin bahsettiğiniz duruma dair herhangi bir tecrübem bulunmadığından dolayı bir yorum yapamamaktayım.

      Kolay gelsin.

  2. Oguzhan dedi ki:

    Sitenizden .Net Core Identity konularına çalışıyorum.Önceden twitter için yaptıığım 3 katmanlı (Data , Core ve UI) bir MVC yapısı var.Identity konusunda ise kafam karıştı müsait olunca cevaplayabilirseniz sevinirim.Sorularım şunlar:
    1)Identity için oluşturacağımız context ve entityler hangi katmanda olmalı ? (Normalde diğer tüm entitiylerim ve contextim data katmanında bulunuyordu ama sizin sitenizde incelerken direkt UI yani mvc(Controller vs. tarafında) örneklendirmişsiniz)
    2)Benim daha önce oluşturduğum tablolarda User isminde tablom vardı ve diğer tablolar ile ilişkileri var.Bundan dolayı AppUser olarak yazdığımız class da sonuç olarak bir User tablosunun özelliklerini barındıyor.Bunun için eski kullandığım User tablosu yerine yeni bunu kullanmak istiyorum ancak eskiden Context sınıfım DbContextten türüyordu ancak AppDbContext IdentityContextten türemesi gerektiğinden nasıl bir çözüm üretebileceğimi bulamadım yardımcı olursanız sevinirim.
    3)Son olarak 2.soruyla bağlantılı olarak Identity için ayrı bir Db oluşturmak gerekli midir yoksa tek bir database içerisinde identity tablelarınında aynı yerde tutulması daha mı sağlıklıdır?
    Eski Db içerisindeki tablolarımı ekledim inceleyebilirseniz sevinirim.Ayrı bir Db gerekiyorsa 2 databasede de User tablosu oluyormuş gibi geldi.
    İyi Çalışmalar

    • Gençay dedi ki:

      Öncelikle merhaba.

      1-) Context ve entityler data ile ilgili olacağı için ‘Data’ katmanında tutulabilir.
      2-) IdentityDbContext, DbContext’i kapsayan ve ekstradan içerisinde Identity mekanizmasında kullanılacak olan DbSet’leri barındıran bir context’tir. Siz, ‘User’ isimli class’ınızı IdentityUser sınıfından türetiniz ve direkt olarak IdentityDbContext ile çalışıp devam edebilirsiniz.
      3-) Hayır. Mevcut database’den devam edebilirsiniz.

      Kolay gelsin.

      • Oğuzhan dedi ki:

        1.soru ile ilgili olarak data katmanı ui katmanı ile doğrudan ilişkili olmaması gerektiğinden (referans verme açısından) startupda identity service eklerken kullandığım classlari Core katmanında DTOlarini oluşturarak o classlari mi kullanmalıyım service tanımlanmasında ?
        3. soruya ek olarak Eger ben identityi ayrı bir veritabanında tutmak istersem(ne kadar doğru bir tasarım bilmiyorum??) normal user tablosuyla identitynin oluşturacağı aspnetuser tablosunu nasıl bağlayabilirim ?(örneğin bir Crud işlemi yaptığımda her iki tabloda da işlem yaparak mi gidilmeli ?)Çok sağlıklı bir yöntem olarak gelmedi zaten bu ama bu şekilde bir dizaynda nasıl bir yol izlenmeli ?
        Teşekkürler

        • Gençay dedi ki:

          1-) Evet, bu durumda doğrusu davranış olacaktır.
          2-) Microservice tasarımlarda olduğu gibi veritabanını bölmek demek ortaya transaction zorluğu getirmektedir. Gerçi sizin çalışmanız monolithic olduğu için transaction kontrolünü yapmanız çok daha kolaydır. Lakin özellikle bu tarz bir senaryoda veritabanını bölmenizi tavsiye etmediğimi öncelikle ifade ediyorum. Ha illa böleceğim diyorsanız veri tutarlılığını sağlayabilmeniz için her iki tabloda gerekli operasyonları yapmanız önemli tabi. Dizayn konusunda pek yardımcı olamayacağım.

          Kolay gelsin.
          Sevgiler.

  1. 11 Ağustos 2019

    […] Asp.NET Core Identity – Veritabanı Tablolarını İnceleyelim – III […]

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

*