Keycloak’ta Hazır Gelen Client’ları, Görevlerini ve Client’larla İlgili Scope ve Rolleri İnceleyelim #2

Merhaba,

Bu içeriğimizde, Keycloak platformunda hazır bir şekilde gelen client’ları inceleyecek, bunların bizlere hazır olarak sunulmasının nedenselliği eşliğinde, görevlerini ve işlevlerine göre neden ve nasıl özel dokunuşlar gerektirebileceklerini ve yapılandırılabileceklerini değerlendirecek ve son olarak da, özel client tanımlarını hangi şartlarda neye göre yapmamız gerektiği ve distributed bir sistemde bulunan tüm servisler için bir client’ın özel olarak tanımlanıp tanımlanmaması durumu üzerine istişare edeceğiz. Hazırsanız, başlayalım…

Keycloak’ta ‘Client’ Ne Demektir?

Client, kelimenin bilinen anlamıyla -istemci- demektir. Bir sistemde kendisine tanımlanmış yetkiler çerçevesinde, bir sunucunun sunduğu servisleri tüketen ve bu servislerle etkileşime geçen aktördür. Bu aktör; kimi zaman bir uygulama, kimi zaman bir servis ya da API olabilir… Ancak yazılımsal terminoloji açısından bakıldığında, Client hiçbir zaman bir kullanıcıyı ifade etmemektedir! Kullanıcıdan ziyade, kullanıcı adına veya bağımsız olarak (illa kullanıcıyla ilişkili işlevler olmak zorunda olmaksızın) hareket eden yazılımsal bileşeni temsil etmektedir.

Keycloak özelinde Client kavramı ise, herhangi bir distributed sistemde kimlik doğrulama ve yetkilendirme hizmeti verilen her bir uygulamayı, servisi veya agent’ı temsil eden işlevsel bir soyutlamadır. Bu nedenle mimaride yer alan istemcileri Keycloak tarafında temsil ederken, rastgele veya anlamsız isimlendirmeler yerine, kavramın teknik karşılığını doğrudan yansıtan Client teriminin tercih edilmesi son derece tutarlı ve yerindedir.

Keycloak’un kendisi de distributed sistemin bir parçası olduğu için kendi kendisini Client olarak tanımlamaktadır.

Neden Bazı Client Tanımları Hazır Olarak Gelmektedir?

Temel neden şudur ki; Keycloak’da hazır olarak gelen client’lar, Keycloak’ın kendi çekirdek (core) fonksiyonlarının OAuth2 / OIDC kurallarına göre çalıştığını göstermek ve bu fonksiyonları güvenli bir şekilde işletmek için gelmektedirler.

Ayrıca; Keycloak’ın kendisi de sistemde tanımlanmış bir client olmasından dolayı, kendi temel işlevlerine karşılık hazır client’lar sunması gerekmektedir. İşte bu client’lardan kimi Web UI ve Admin paneli sunmakta, kimi de REST API ya da CLI sunmaktadır. Bunların her biri client olarak sistemin başlangıcında tarafımıza sunulmaktadır.

Bunların dışında hazır client’lar ile Keycloak minimum gereksinimlerle çalışabilir realm garantisi sunmaktadır. Yani Keycloak, en yalın haliyle bir realm oluşturulduğu anda -bu realm ile kullanıcı login olabilir, hesabını yönetebilir ve admin erişimi sağlayabilir- garantisini vermektedir. Ee bu garantinin verilebilmesi için de hesaplarla ilgilenen (account) ve admin paneli sunabilen (admin) client’ların hazır gelmesi zorunluluk gerektirmektedir. İşte bu mantıktan dolayı, Keycloak’da bir realm oluşturulduğu anda tüm bu yeteneklerin doğal olarak sunulabilmesi için her realm’de diğerlerinden izole bir şekilde bu client’lar hazır olarak gelecektir.

Neden bu hazır gelen client’ları biz oluşturmuyoruz?
Derdin ne kardeşim 🤣 İşi gücü bırakıp hassas ayar gerektiren bu client’ların tanımlamasını yapmanın ve bunu her realm oluşturduğunda tekrar tekrar sağlayacak şekilde bir altyapı kurmaya çalışmanın ciddi maliyet gerektireceği aşikar! Keycloak hazır olarak oluşturduğu client’lar ile baştan belli olan bir sistem sözleşmesi sunmakta ve bu sayede biz geliştiriciler de buna güvenerek çalışmalarımıza ve business logic tarafına rahatlıkla odaklanabilmekteyiz.

Keycloak’da her realm içinde gelen hazır client’lar genellikle Keycloak’ın kendi işlevselliğini sağlaması için gelmektedirler.

Nihai olarak özetlersek eğer; hazır gelen client’lar, Keycloak’ın kendi sunduğu tüm arayüz ve servislerin de standart OAuth2 / OIDC client’ları olarak çalışmasını sağlamak, güvenlik ve tutarlılığı garanti etmek için sistemle birlikte gelmektedirler.

Hazır Gelen Client’ları İnceleyelim…

Keycloak’da bir realm oluşturulduğu anda (ya da master realm kullanıldığında) içerisinde aşağıdaki görseldeki client’ların hazır olarak geldiği görülmektedir.Şimdi bizler bu client’ları tek tek inceleyecek ve ne işe yaradıklarını, neden var olduklarını vs. sorgulayacağız.

• account
  Ne işe yarar?
  Kullanıcının şifre değiştirme, e-posta güncelleme, MFA / OTP ayarlarını gerçekleştirme, o ana kadar olan session’larını listeleme ve hesabına bağlı uygulamaları görme gibi işlemleri sağladığı kendi hesabına dair yönettim arayüzü sunan Account Management UI‘a karşılık gelen client’tır.

  Zorunlu mu? ✅

  Bu client, özünde kullanıcının kendi hesabını yönetebilmesi (self-service) için sunulmuş bir web uygulamasıdır. Dolayısıyla bu uygulamanın bir entry-point URL’si mevcuttur. Teknik olarak; account client’ı backend API’leri sağlarken, account-console client’ı ise frontend (HTML/JS)’i sağlamaktadır.

  URL:

  /realms/{realm}/account

  http://127.0.0.1:8080/realms/master/account

  Bu URL üzerinden kullanıcı kendi hesabına dair müdahalede bulabileceği bir arayüze erişebilecektir.

• account-console
  Ne işe yarar?
  account client’ının API’lerini kullanarak kullanıcıya frontend (JS tabanlı) yönetim panelini sağlayan client’tır.

  Peki neden ayrı client olarak tanımlanmıştır?
  Security sebebiyledir. Çünkü; UI client dışardan erişilebilirken, backend ise haliyle gizli olmak mecburiyetindedir. Bu iki kutuplu güvenlik endişelerini yönetebilmek için her iki uygulamayı farklı client olarak görmekteyiz.

  Zorunlu mu? ✅

• admin-cli
  Ne işe yarar?
  Keycloak’ın tüm yönetimsel (admin) REST API’lerine erişim sağlayan, sistem seviyesinde yetkilere sahip olan resmi client’ıdır. Bir UI değildir! Sadece CLI’da değildir! Ve unutulmamalıdır ki, Keycloak’ın yönetim kapısıdır!

  admin-cli ile yapılacaklardan ziyade yapılamayacaklardan bahsetmek daha temiz bir izah olacaktır diye düşünüyorum. Şöyle ki; admin-cli ile,
  ❌Kullanıcı login etmezsiniz!
  ❌Business API çağırmazsınız!
  ❌Uygulama authentication işlemlerini yürütmezsiniz!
  ✅Yalnızca Keycloak’ın kendisini yönetirsiniz.

  admin-cli ile realm’ler, user’lar, client’lar, role’lar, identity provider’lar ve policy’ler doğrudan yönetilebilmektedir. İşte admin-cli tüm bu işlevlerin endpoint’lerine erişebilmek için mevcuttur.

  admin-cli token’ı bir root yetkisidir!

  acmin-cli token’ı, yalnızca Keycloak’ın Admin REST API alanına erişimi temsil etmektedir. Yani bu token ile uygulama dünyasının tüm yetkilendirmelerini değil, yalnızca identity altyapısını yönetebilmekteyiz. Buradaki ayrımın farkındalığı bizler için kritiktir! Haliyle bu farkındalıkla, admin-cli’ın token’ı her şeye erişebilir mi? sorusuna karşılık ‘hayır’ cevabını verebiliriz. Burada şöyle düşünebilirsiniz; admin-cli, client oluşturabilir ancak o client adına login olamaz 😉 Bir başka örnek vermemiz gerekirse eğer uygulama üzerinden yeni realm oluşturulacaksa admin-cli token’ı kullanılır, ancak bu token ile uygulama sayfalarına erişim gerçekleştirilemez! Bu erişim için application client token’ı gerekir…

  admin-cli token’ı ile uygulama iş mantığına ASLA girilmez!

  Zorunlu mu? ⚠️ Teknik olarak silinebilir! Ancak önerilmez!

• security-admin-console
  Ne işe yarar?
  Keycloak’un, -ben bile kendimi OAuth2 / OIDC ile authenticate ederim- felsefesiyle hareket etmesinden kaynaklı Admin UI’ının kendisini temsil eden bir client’tır. Yani, Keycloak ‘ben özelim’ dememekte ve kendini bir client olarak tanımlayıp, authenticate etmektedir.

  Keycloak’a bir yönetim arayüzü sunmasından kaynaklı haliyle bir web uygulamasıdır ve aşağıdaki gibi bir entry-point’i mevcuttur.

  URL:

  /admin

  http://127.0.0.1:8080/admin

  Zorunlu mu? ✅

• broker
  Ne işe yarar?
  Keycloak ile başka bir kimlik sistemi arasındaki aracı mekanizmayı temsil eden client’tır. Google Login, Azure AD, LDAP vs. gibi harici oturum açma süreçlerini yürütmektedir. Yapısal olarak; Google’dan dönen token, Azure AD’den dönen assertion veya başka Keycloak’tan gelen identity önce broker client’ı tarafından karşılanmaktadır.

  Google, Azure AD vs. gibi external identity provider’lar redirect + callback mekanizmasıyla çalıştıklarından dolayı broker client’ı aşağıdaki gibi bir callback URL’i sunmaktadır.

  URL:

  /realms/{realm}/broker/{provider}/endpoint

  Bu url üzerinden, external identity provider’dan dönen token elde edilebilmekte, kullanıcı Keycloak user’ına eşleştirilebilmekte ve ilk login sağlanabilmekte ya da user oluşturulabilmektedir. Bu tarz bir işlevselliğe sahip olduğu için bu url bir arayüz misali kullanılmaz, yalnızca protokol seviyesinde çalışma sergiler. Bundan kaynaklı bu url kullanıcı tarafından değil, external identity provider tarafından çağrılır.

  Zorunlu mu? ⚠️

  broker, Keycloak’ın Google, Azure AD, LDAP veya başka bir Keycloak gibi external identity provider’larla konuşabilmesi için kullandığı sistem client’ıdır.

• master-realm
  Ne işe yarar?
  master-realm client’ı, Keycloak’ın kendi admin işlemleri için kullandığı iç servis client’ıdır. Yani, geliştirilen uygulama için varlık göstermemektedir. Keyclock, kendi kendisiyle konuşurken aşağıdaki işlemler için bu client’ı kullanmaktadır.

  master-realm client’ından elde edilen token ile realm listelerini çekmek, admin UI sayfalarını render etmek, admin REST endpoint’lerine arka plandan erişmek, role/permission resolve etmek, session & cache senkronizasyonunu sağlamak vs. gibi internal (sunucu içi) admin işlemleri yürütülmektedir. Ancak burada dikkat edilmesi gereken husus şudur ki, bu işlemlerin hiçbiri kullanıcı adına değildir, Keycloak adına gerçekleştirilir!

Client Detayları ve Oluşturulma Süreci

Client oluştururken; “Bu client, token’ı kim adına ve nasıl alacak?” sorusu sorulmalıdır…

Evet, client oluşturma sürecinde dikkat edilmesi gereken temel husus bu soruya verilen cevapla şekillenecektir. Şöyle ki;

• “Bu client, bir frontend uygulaması mı, backend çalışması mı?”
  Flow ve client type bu duruma göre değişkenlik gösterecektir…
• “Kullanıcı olacak mı?”
  Authorization Code mu, Client Credentials mı olup olmayacağı bu soruya göre şekillenecektir…
• “Secret güvenli saklanabilir mi?”
  Public ya da Confidential olup olmaması buna bağlı…
• “Uygulama tarayıcıda mı çalışacaktır?”
  PCKE zorunluluğu buna bağlı…
• “Sadece API mi?”
  Redirect URI gerekecek mi, gerekmeyecek mi…

Doğru soru(lar) ve doğru cevap(lar) edinildikten sonra artık oluşturulacak client’ın türü belirlenecektir.

Peki bu CLIENT türleri nelerdir?

Keycloak’da, bir client oluştururken öncelikle bu client’ın hangi standart üzerinden konuşacağı belirlenmelidir. Bu ilk etapta OpenID Connect veya SAML olarak ayarlanabilmektedir.

Bizler, güncel ve modern mimariler için bir client oluştururken neredeyse her zaman OpenID Connect (OIDC) türünden bir seçim yapacağımızı şimdiden söyleyebiliriz. Çünkü; web uygulamaları, SPA’ler, mobil uygulamalar, backend servisler ve mikroservisler JWT tabanlı, hafif ve esnek yapısı nedeniyle OIDC ile çok daha kolay ve güvenli biçimde sürece entegre edilebilirler. SAML ise genellikle mevcut kurumsal/legacy sistemlerde entegrasyon zorunluluğu varsa tercih edilmektedir. Bu yüzden, yeni bir sistem tasarlarken -ilk seçenek- değildir!

Devamında ise eğer client, OpenID Connect türünde oluşturulduysa erişim türünü de belirlemek gerekmektedir. Bu, ilgili client’ın token alırken nasıl davranacağını ve sırları koruyup korumayacağını belirleyecektir.

Keycloak’da client oluştururken aşağıdaki arayüzden istifade edilmektedir.Burada dikkat ederseniz client erişim türüne dair bir dropdown görülmemektedir. Bu bir eksiklikten ziyade bilinçli bir tasarımsal destektir. Şöyle ki, bu arayüz üzerinden oluşturulacak client’a dair yapılan konfigürasyon neticesinde client türü yapılandırmadan dinamik bir şekilde türetilecektir. Yani Keycloak, client’ın davranışına bakarak, ona göre bunun public, confidential ya da bearer-only olup olmadığına karar verecektir.

Burada kritik anahtar olarak Client authentication‘ı almak gerekmektedir. Bu eğer;

• ‘Off’ ise client secret yok demektir. Ee haliyle client kimliğini kanıtlayamayacağı için türe direkt Public Client‘tır diyebiliriz.
• ‘On’ ise client secret / private key vardır demektir. Ee bu da bizi Confidential Client‘a götürecektir.

Yani tek başına bu ayar Public vs Confidential ayrımını yapmak için yeterlidir.

Eğer ki, tüm flow’lar kapalıyken, client authentication ‘Off’ ise bu da Bearer-only Client‘a karşılık gelecektir.

Tüm bu süreçte client tanımı için bir Client ID değerine ihtiyaç olacaktır. Bu değer, tahmin edileceği üzere unique olmak zorundadır. Token içerisinde aud, azp gibi alanlarda gözükecektir.

Ayrıca client oluşturma sürecinde Always display in UI alanını ‘On’ yaparak, bu client’ın scope’ları kullanıcı onay (consent) ekranında her zaman görüntülenebilir yapılabilmektedir.

CLIENT Scope’ları

Keycloak’da scope, token içerisine hangi claim’lerin ekleneceğini belirleyen teknik bir kavramdır. Bu nedenle client’lar bazında scope tanımlanabilmektedir çünkü, her client için üretilecek token’a eklenecek bilgiler farklılık gösterebilmektedir. Ancak bu her client için ayrı ayrı scope tanımlamak zorundayız anlamına gelmemektedir! Keycloak’da, ortak ihtiyaçlar için tanımlanan scope’lar birden fazla client tarafından paylaşılabilmektedir. Onun için sonraki satırlarda bahsedeceğimiz üzere, scope’lar önce genel tanımlanmakta, ardından istenilen client ile ilişkilendirilebilmektedir.

Şimdi gidip Keycloak’da mevcut client’ları kurcalarsanız, göreceksiniz ki, kiminde scope var kimin de yok! Bunun nedeni bu client’ların farklı amaçlara hizmet etmesidir. Şöyle ki; client’ların bir kısmı Standart (OIDC) kullanıcı odaklı davranış sergilerken, bir kısmı ise teknik yani sistemle alakalı davranışlar sergilemektedir.

• Standart (Kullanıcı Odaklı) Client’lar

  Bir kullanıcı oturum açtığında; authorization code, PKCE vs. gibi OIDC akışlarını kullanan ve scope’larla çalışan client’lardır.openid scope’unun bunlarda zorunlu olması ortak özellikleridir. Ayrıca profile, email vs. gibi scope’lar eşliğinde custom scope’lar da kullanırlar.

  Keycloak’da mevcut standart client’lar : account, account-console ve security-admin-console‘dur.

  Keycloak dashboard’u üzerinden standart client’lara baktığınızda hiçbirinde openid diye bir scope’un bulunmadığını görebilirsiniz! Eee hani hoca bunlarda openid bulunmak zorundaydı la! dediğinizi duyar gibiyim… 🙂 Evet, sakin olun. openid zorunludur, ancak ayrı bir scope olarak görünmesine gerek yoktur. Çünkü openid, OIDC protokolünün ta kendisidir de ondan 🙂 Haliyle Keycloak, zaten OpenID Connect olarak oluşturulan bir client’ta bu scope’u otomatik ve örtük (implicit) bir şekilde yönetmektedir. Ha illa openid scope’unu görmek isterseniz, sonraki seviyelerde authorization isteklerinde zahiren göreceksiniz. Bunun dışında ID Token üretimi süreçlerinde openid olmazsa olmazdır ve o noktalarda da varlığını net bir şekilde gösteriyor olacaktır.

  OIDC kullanan client’larda openid scope’u protokol seviyesinde zorunludur. Ancak, Keycloak’ta bu scope her zaman UI’da görünmez ve çoğu built-in client için implicit olarak kabul edilir.

• Teknik / Sistem (Service) Client’lar
  Kullanıcıyı değil sistemi temsil eden, arka planda çalışan ve scope yerine role ile yetkilendirilen client’lardır. Genelde client_credentials kullanırlar.

  Keycloak’da admin-cli, broker ve master-realm teknik işlevsellik gösteren client’lardır.

  Teknik client’lar, kullanıcıyı temsil etmek zorunda olmayan client’lardır.

Keycloak’da custom OIDC bir client oluşturulduğu zaman minimum OIDC davranışlarını garantiye alacak şekilde bazı tanımlanmış scope’lar otomatik olarak bu client’la ilişkilendirilecektir. Yani bir custom client oluşturulduğu anda belli başlı scope’larla gelecektir.

Bu otomatik gelen scope’lar nereden gelmektedir?
Realm altında tanımlanmış olan ‘Client scopes’lardan.

Tabi burada scope türü de bizler için önem arz etmektedir. Şöyle ki;

Eğer ki bir scope ‘Default’ olarak tanımlanmışsa, her daim gerekli olarak nitelendirilir ve eşleştirildiği client için token üretilirken, istekten bağımsız bir şekilde otomatik olarak o token’a eklenir.

‘Optional’ olarak tanımlanmışsa, scope parametresinde özellikle belirtildiği sürece token’a eklenir. Misal olarak; phone optional bir scope olduğu için bunu token talebi sürecinde token’a eklemek istersek ‘scope=openid phone’ şeklinde belirtmemiz gerekir. (Burada openid ile birlikte belirtilmesinin sebebi ID Token‘ı elde edebilmektir, aksi taktirde ID Token yoksa user claim’leri anlamsızlaşmaktadır ;))

Bunların dışında ‘None’ olarak tanımlanmışsa bu client bu scope’u kullanamayacaktır. scope parametresinde belirtilse bile yok sayılacak ve üretilecek token’a eklenmeyecektir.

CLIENT Roles

Keycloak’da role ise bir eylemi gerçekleştirebilecek izni/yetkiyi temsil eden bir ifadedir ve Realm Roles, Client Roles ve Built-in Roles olmak üzere üçe ayrılır.

• Realm Roles
  Realm seviyesinde tanımlanan ve tüm client’lar için geçerli olan rollerdir.

  Misal olarak; admin, offline_access ve uma_authorization realm seviyesinde tanımlanmış hazır rollerdir.

• Client Roles
  Belirli bir client’a bağlı olan ve sadece o client için anlam ifade eden rollerdir.
• Built-in Roles
  Bunlar ise sırada roller değildir! Keycloak bunları davranış tetikleyici roller olarak kullanmaktadır.
  • offline_access
    Kullanıcıya refresh token alma yetkisi veren özel roldür.
  • admin
    Realm yönetim yetkilerini açar. Admin REST API erişimini belirler.
  • uma_authorization
    Bu rol, ilgili client’ın Authorization Services (Policy Engine) kullanılabilirliğini aktif hale getirir.

    Peki Authorization Services ne demektir?
    Normalde Keycloak’ta yetkilendirme şöyle cereyan etmektedir;

    → token gelir
    → role var mı kontrol edilir
    → varsa işleme izin verilir

    Authorization Services aktif olursa eğer;

    → token gelir
    → hangi resource olduğu değerlendirilir
    → hangi action olduğu değerlendirilir
    → hangi policy olduğu değerlendirilir
    → hangi condition olduğu değerlendirilir
    → değerlendirmeler olumluysa işleme izin verilir

    Buradan anlayacağınız Policy Engine‘in aktif edilmesi demek detaylı bir politika davranışının kontrolü demektir. Normalde, -şu yetki varsa işleme izin ver- mantığı, -şu yetki varsa, saat 09-18 arasıysa, kullanıcı şuysa, IP güvenliyse vs. vs. vs. işleme izin ver- şeklinde daha teferruatlı bir hal almaktadır.

    Yani, Authorization Services’de rol değil, policy değerlendirmesi gerçekleştirilir.

    uma_authorization rolü ise Keycloak’a şunu söyler : -Bu client bir resource server’dır ve policy ile korunacaktır-

    Bu rol, kullanıcıya değil client’a verilir. Teknik bir roldür.

Roller; kullanıcılara, gruplara ve service account üzerinden client’lara verilebilir.

Ayrıca hazır lafı gelmişken token’a eklenmiş bir rolün nasıl gözüktüğünü aşağıda resmetmekte fayda görmekteyim:

"realm_access": {
  "roles": ["offline_access", "user"]
}
"resource_access": {
  "order-service": {
    "roles": ["order.read"]
  }
}

Peki, bir client’a rol nasıl atayabilirim?
Bu başlı başına rollerle ilgili hususi olarak incelemede bulunacağımız içeriğin konusu. Ancak, burada akıllarda soru işareti kalmaması için yüzeyselde olsa bu suali cevaplandırmaya çalışacağım.

Öncelikle şunu bilmek gerekiyor ki, Keycloak’ta rol her daim bir özneye (principal) atanmalıdır. Client’ın kendisi ise özne değildir! Client’ın service account’u olur. Haliyle rol verilecek client teknik bir client olmalıdır ve aşağıdaki gibi Settings sekmesi üzerinden Service Account‘u açılmalıdır.Bu yapılandırmadan sonra tanımlanan rol rahatlıkla client’a atanabilir. Bunun için client’ın Service account roles sekmesine giderek rol ataması gerçekleştirilebilir.

Keycloak Client’lara Dair 5 Kritik Soru & Cevap

Şimdi son olarak, konuya dair ortak bir bağlamda olmayan ancak açıklığa kavuşturulması gereken bazı önemli hususları soru / cevap şeklinde aşağıda toparlayarak bu içeriğimizi nihayetlendirelim.

Nihai olarak;

Bu içeriğimizde Keycloak’taki hazır gelen client tanımlarını, bu client’ların davranışlarını ve görevlerini, bu client’ların dışında sistemde varlık gösterip yetkilendirilecek olan client’ların özel olarak tanımlanmasının kritiğini gerçekleştirmiş bulunuyoruz. Bunların yanında client’lara anlam kazandıran scope ve role ifadelerini client kapsamında detaylıca değerlendirmiş ve arayüz eşliğinde pratiksel dokunuşlarla eşlik etmiş bulunuyoruz. Bundan sonraki içeriklerimizde artık kavramlarını ve işleyiş mantığını anlamaya başladığımız Keycloak’u API üzerinden de nasıl yönetebileceğimizi ve uzaktan yapılandırabileceğimizi değerlendirecek, özellikle bu içerikte bahsettiğimiz scope ve role yapılandırmalarının farklı uygulamalar üzerinden nasıl gerçekleştirilebileceğini tecrübe edeceğiz.

İlgilenenlerin faydalanması dileğiyle…
Sonraki yazılarımda görüşmek üzere…
İyi çalışmalar…