Firebase kullanıcı nesnesi, projenizdeki bir uygulamaya kaydolan bir kullanıcı hesabını temsil eder. Uygulamaların genellikle çok sayıda kayıtlı kullanıcısı vardır ve bir projedeki her uygulama bir kullanıcı veritabanını paylaşır.
Kullanıcı örnekleri, Firebase Kimlik Doğrulaması örneklerinden bağımsızdır, bu nedenle aynı bağlamda farklı kullanıcılara birkaç referansınız olabilir ve yine de onların yöntemlerinden herhangi birini çağırabilirsiniz.
Kullanıcı özellikleri
Firebase kullanıcıları, projenin kullanıcı veritabanında depolanan ve kullanıcı tarafından güncellenebilen ( iOS , Android , web ) sabit bir temel özelliklere (benzersiz bir kimlik, birincil e-posta adresi, ad ve fotoğraf URL'si) sahiptir. Kullanıcı nesnesine doğrudan başka özellikler ekleyemezsiniz; bunun yerine, ek özellikleri Google Cloud Firestore gibi diğer tüm depolama hizmetlerinde depolayabilirsiniz.
Bir kullanıcı uygulamanıza ilk kaydolduğunda, kullanıcının profil verileri mevcut bilgiler kullanılarak doldurulur:
- Kullanıcı bir e-posta adresi ve parola ile kaydolduysa yalnızca birincil e-posta adresi özelliği doldurulur
- Kullanıcı, Google veya Facebook gibi bir birleşik kimlik sağlayıcıya kaydolduysa, sağlayıcı tarafından sağlanan hesap bilgileri, kullanıcının profilini doldurmak için kullanılır.
- Kullanıcı, özel kimlik doğrulama sisteminizle kaydolduysa, istediğiniz bilgileri açıkça kullanıcının profiline eklemelisiniz.
Bir kullanıcı hesabı oluşturulduktan sonra, kullanıcının başka bir cihazda yapmış olabileceği değişiklikleri dahil etmek için kullanıcının bilgilerini yeniden yükleyebilirsiniz.
Oturum açma sağlayıcıları
Birkaç yöntem kullanarak uygulamalarınızda kullanıcıların oturumunu açabilirsiniz: e-posta adresi ve parola, birleştirilmiş kimlik sağlayıcıları ve özel kimlik doğrulama sisteminiz. Bir kullanıcıyla birden fazla oturum açma yöntemi ilişkilendirebilirsiniz: örneğin, bir kullanıcı aynı hesapta bir e-posta adresi ve şifre kullanarak veya Google ile Oturum Açma özelliğini kullanarak oturum açabilir.
Kullanıcı örnekleri, kullanıcıya bağlı her sağlayıcıyı takip eder. Bu, bir sağlayıcı tarafından verilen bilgileri kullanarak boş profilin özelliklerini güncellemenizi sağlar. Bkz. Kullanıcıları Yönetme ( iOS , Android , web ).
mevcut kullanıcı
Bir kullanıcı kaydolduğunda veya oturum açtığında, bu kullanıcı Auth örneğinin geçerli kullanıcısı olur. Örnek, kullanıcının durumunu korur, böylece sayfayı yenilemek (bir tarayıcıda) veya uygulamayı yeniden başlatmak kullanıcının bilgilerini kaybetmez.
Kullanıcı oturumu kapattığında, Kimlik Doğrulama örneği, kullanıcı nesnesine bir referans tutmayı durdurur ve durumunu artık sürdürmez; mevcut kullanıcı yok. Bununla birlikte, kullanıcı örneği tamamen işlevsel olmaya devam eder: ona bir referans verirseniz, yine de kullanıcının verilerine erişebilir ve bunları güncelleyebilirsiniz.
kullanıcı yaşam döngüsü
Auth örneğinin mevcut durumunu izlemenin önerilen yolu, dinleyicileri (JavaScript'te "gözlemciler" olarak da adlandırılır) kullanmaktır. Bir Auth dinleyicisi, Auth nesnesiyle alakalı bir şey olduğunda bilgilendirilir. Bkz. Kullanıcıları Yönetme ( iOS , Android , web ).
Bir Auth dinleyicisi aşağıdaki durumlarda bildirim alır:
- Auth nesnesi başlatmayı bitirir ve bir kullanıcı zaten önceki bir oturumda oturum açmıştır veya bir kimlik sağlayıcının oturum açma akışından yeniden yönlendirilmiştir.
- Bir kullanıcı oturum açar (mevcut kullanıcı ayarlanmıştır)
- Bir kullanıcı oturumu kapatır (geçerli kullanıcı boş olur)
- Geçerli kullanıcının erişim belirteci yenilenir. Bu durum aşağıdaki koşullarda gerçekleşebilir:
- Erişim belirtecinin süresi doluyor: bu yaygın bir durumdur. Yenileme jetonu, geçerli yeni bir jeton seti almak için kullanılır.
- Kullanıcı parolasını değiştirir: Firebase, yeni erişim ve yenileme belirteçleri yayınlar ve eski belirteçlerin süresinin dolduğunu gösterir. Bu, güvenlik nedenleriyle kullanıcının belirtecini otomatik olarak sona erdirir ve/veya her cihazda kullanıcının oturumunu kapatır.
- Kullanıcı yeniden kimlik doğrulaması yapar: bazı işlemler, kullanıcının kimlik bilgilerinin yakın zamanda verilmiş olmasını gerektirir; bu tür eylemler bir hesabı silmeyi, birincil e-posta adresini ayarlamayı ve bir parolayı değiştirmeyi içerir. Kullanıcının oturumunu kapatıp tekrar oturum açmak yerine, kullanıcıdan yeni kimlik bilgileri alın ve yeni kimlik bilgilerini kullanıcı nesnesinin yeniden kimlik doğrulama yöntemine iletin.
kullanıcı self servis
Varsayılan olarak Firebase, kullanıcıların yönetici müdahalesi olmadan kaydolmalarına ve hesaplarını silmelerine olanak tanır. Çoğu durumda, bu, son kullanıcıların uygulamanızı veya hizmetinizi ve gemide (veya gemi dışında) minimum sürtüşme ile keşfetmesini sağlar.
Ancak, kullanıcıların Admin SDK veya Firebase konsolu kullanılarak bir yönetici tarafından manuel veya programlı olarak oluşturulmasını istediğiniz durumlar vardır. Bu durumlarda, son kullanıcılar tarafından hesap oluşturulmasını ve silinmesini önleyen Firebase Kimlik Doğrulama Ayarları sayfasından kullanıcı eylemlerini devre dışı bırakabilirsiniz. Çoklu kiracılık kullanıyorsanız, bu özellikleri kiracı bazında devre dışı bırakmak için bir HTTP isteğinde bulunmanız gerekir.
Bir son kullanıcı, sisteminizde bir hesap oluşturmaya veya silmeye çalışırsa Firebase hizmeti bir hata kodu döndürür: Web API çağrıları için auth/admin-restricted-operation veya Android ve iOS için ERROR_ADMIN_RESTRICTED_OPERATION . Kullanıcıdan hizmetiniz için uygun eylemleri gerçekleştirmesini isteyerek ön uçtaki hatayı zarif bir şekilde ele almalısınız.
Yetkilendirme belirteçleri
Firebase ile kimlik doğrulama gerçekleştirdiğinizde, karşılaşabileceğiniz üç tür kimlik doğrulama jetonu vardır:
| Firebase kimliği belirteçleri | Kullanıcı bir uygulamada oturum açtığında Firebase tarafından oluşturulur. Bu belirteçler, bir Firebase projesinde bir kullanıcıyı güvenli bir şekilde tanımlayan imzalı JWT'lerdir. Bu belirteçler, kullanıcının Firebase projesine özgü kimlik dizesi de dahil olmak üzere, bir kullanıcı için temel profil bilgilerini içerir. Kimlik belirteçlerinin bütünlüğü doğrulanabileceğinden , bunları şu anda oturum açmış kullanıcıyı tanımlamak için bir arka uç sunucusuna gönderebilirsiniz. |
| Kimlik sağlayıcı belirteçleri | Google ve Facebook gibi birleştirilmiş kimlik sağlayıcıları tarafından oluşturulmuştur. Bu belirteçler farklı biçimlere sahip olabilir, ancak genellikle OAuth 2.0 erişim belirteçleridir. Uygulamalar, kullanıcıların kimlik sağlayıcıda başarılı bir şekilde kimlik doğrulaması yaptığını doğrulamak ve ardından bunları Firebase hizmetleri tarafından kullanılabilen kimlik bilgilerine dönüştürmek için bu belirteçleri kullanır. |
| Firebase özel belirteçleri | Kullanıcıların, kimlik doğrulama sisteminizi kullanarak bir uygulamada oturum açmasına izin vermek için özel kimlik doğrulama sisteminiz tarafından oluşturulmuştur. Özel belirteçler, bir hizmet hesabının özel anahtarı kullanılarak imzalanan JWT'lerdir. Uygulamalar, bu belirteçleri, birleştirilmiş kimlik sağlayıcılarından döndürülen belirteçleri kullandıkları gibi kullanır. |
Doğrulanmış e-posta adresleri
Firebase, iki koşulu karşılayan bir e-postayı doğrulanmış olarak kabul eder:
- Kullanıcı, Firebase doğrulama akışını tamamlar
- E-posta, güvenilir bir Kimlik Sağlayıcı veya kısaca IdP tarafından doğrulanır.
E-postayı bir kez doğrulayan, ancak daha sonra kullanıcıların yeniden doğrulama gerektirmeden e-posta adreslerini değiştirmesine izin veren IdP'lere güvenilmez. Etki alanına sahip olan veya her zaman doğrulama gerektiren IdP'ler güvenilir kabul edilir.
Güvenilir sağlayıcılar:
- Google (@gmail.com adresleri için)
- Yahoo (@yahoo.com adresleri için)
- Microsoft (@outlook.com ve @hotmail.com adresleri için)
- Apple (her zaman doğrulanır, çünkü hesaplar her zaman doğrulanır ve çok faktörlü kimlik doğrulaması yapılır)
Güvenilmeyen sağlayıcılar:
- GitHub
- Söz konusu Kimlik Sağlayıcı tarafından verilmeyen etki alanları için Google, Yahoo ve Microsoft
- E-posta doğrulaması olmadan E-posta / Şifre
Bazı durumlarda, bir kullanıcı aynı e-posta adresini kullanarak farklı sağlayıcılarda oturum açtığında, Firebase hesapları otomatik olarak bağlar. Ancak bu, yalnızca belirli kriterler karşılandığında gerçekleşebilir. Nedenini anlamak için şu durumu göz önünde bulundurun: Bir kullanıcı, Google'ı kullanarak bir @gmail.com hesabıyla oturum açar ve kötü niyetli bir aktör, aynı @gmail.com adresini kullanarak ancak Facebook üzerinden oturum açarak bir hesap oluşturur. Bu iki hesap otomatik olarak bağlanırsa, kötü niyetli aktör kullanıcının hesabına erişim elde eder.
Aşağıdaki durumlar, hesapları otomatik olarak ne zaman bağladığımızı ve ne zaman kullanıcı veya geliştirici eylemi gerektiren bir hata oluşturduğumuzu açıklamaktadır:
- Kullanıcı güvenilmeyen bir sağlayıcıda oturum açar, ardından aynı e-postayı kullanarak başka bir güvenilmeyen sağlayıcıda oturum açar (örneğin, Facebook ve ardından GitHub). Bu, hesap bağlama gerektiren bir hata verir.
- Kullanıcı, güvenilir bir sağlayıcıda oturum açar, ardından aynı e-postayı kullanarak (örneğin, Google'ın ardından Facebook gelir) güvenilmeyen bir sağlayıcıda oturum açar. Bu, hesap bağlama gerektiren bir hata verir.
- Kullanıcı, güvenilmeyen bir sağlayıcıda oturum açar, ardından aynı e-posta ile güvenilir bir sağlayıcıda oturum açar (örneğin, Facebook ve ardından Google). Güvenilir sağlayıcı, güvenilmeyen sağlayıcının üzerine yazar. Kullanıcı Facebook ile tekrar oturum açmaya çalışırsa, hesap bağlama gerektiren bir hataya neden olur.
- Kullanıcı, güvenilir bir sağlayıcıda oturum açar, ardından aynı e-postayı kullanarak farklı bir güvenilir sağlayıcıda oturum açar (örneğin, Apple ve ardından Google). Her iki sağlayıcı da hatasız bir şekilde bağlanacaktır.
Yönetici SDK'sını kullanarak bir e-postayı manuel olarak doğrulanmış olarak ayarlayabilirsiniz, ancak bunu yalnızca e-postanın gerçekten kullanıcının sahibi olduğunu biliyorsanız yapmanızı öneririz.