Kimlik doğrulama olay tetikleyicileri
Biri kaydolduğunda, e-posta adresini onayladığında, şifresini değiştirdiğinde veya yasaklandığında markanıza uygun e-postalar göndermeye başlamak için Supabase’i bağlayın. Bir kurulum betiği auth.users tablonuza bir veritabanı tetikleyicisi ekler; Brew de her değişikliği 12 otomasyon tetikleyicisinden birine dönüştürür.
Giriş, onay bağlantıları, sihirli bağlantılar ve şifre sıfırlama Supabase Auth hizmetinin sorumluluğunda kalır. Bu değişikliklerin ardından gelen e-postaları ise Brew oluşturur ve gönderir.
auth.user.signed_in olayı, last_sign_in_at değiştiğinde tetiklenir. Supabase’in belirteç yenilemeleri de bu sütunu değiştirdiğinden olay, kullanıcının oturumu açık kaldığı sürece tekrar tekrar tetiklenebilir. Bu olay, birinin uzun bir aradan sonra geri döndüğünü göstermez.
Ayrıca türetilen olaylar arasında önceliği en düşük olan da budur. Aynı güncelleme bir e-posta adresini onaylıyor veya anonim bir kullanıcıyı kalıcı hesaba geçiriyorsa Brew, auth.user.signed_in yerine o olayı üretir.
Hareketsiz kullanıcılara hal hatır soran bir e-posta göndermek için hareketsizliği uygulamanızda, uygulamanın kendi etkinlik verilerine göre belirleyin. Ayrı bir Brew özel olayını yalnızca koşulları karşılayan kullanıcılar için tetikleyin ve e-postayı bu olayla tetiklenen, durumu Yayında olan bir otomasyon göndersin.
İki yolu da test edin: Hareketsiz bir kullanıcı e-postayı alır; kontrolden önce etkin olan bir kullanıcı almaz.
auth.user.created, auth.user.updated ve auth.user.deleted olayları auth.users tablosundaki ekleme, güncelleme ve silme işlemlerinden gelir. Brew diğer olayları, bir güncellemedeki eski ve yeni satırı karşılaştırarak türetir.
Bir güncelleme tek bir olay üretir. Birden fazla sütun aynı anda değiştiğinde şu sıradaki ilk eşleşme geçerli olur: email_confirmed, phone_confirmed, upgraded_from_anonymous, email_changed, password_changed, banned, unbanned, invited, signed_in. Bunların hiçbiriyle eşleşmeyen bir güncelleme auth.user.updated olarak gelir.
Brew şu 12 olay türünü destekler:
Gerçek bir e-posta adresi taşıyan her doğrulanmış olay, bir otomasyon o olayı kullansın ya da kullanmasın, e-posta adresine göre eşleştirilen bir Brew kişisi oluşturur veya mevcut kişiyi günceller. İlgili veriler varsa Brew ad, soyad, supabase_user_id, supabase_phone, supabase_role, supabase_full_name, supabase_avatar_url ve supabase_provider alanlarını doldurur.
Bazı olaylar yaşam döngüsü alanlarını da doldurur. supabase_account_status alanı active, invited, banned veya deleted değerini alır. supabase_email_verified_at, supabase_phone_verified_at ve supabase_last_sign_in_at alanları ilgili onay ve giriş olaylarından gelir.
Birleştirme etiketleri için seçilen olayın tanımlanan payload şemasını kullanın. Her olay email alanını ve varsa firstName, lastName, fullName, displayName, avatarUrl, phone, role, provider, createdAt, lastSignInAt ve emailConfirmedAt alanlarını içerir. Adlar ve avatarlar raw_user_meta_data alanından gelir; OAuth ile kaydolanlar için yedek kaynaklar da kullanılır. Üç zaman damgası da Unix saniyesi cinsindendir.
Türetilen olaylar, eski ve yeni sütun değerini metin olarak tutan previousValue alanını, newValue alanını veya ikisini birden ekler. auth.user.password_changed olayında ikisi de yoktur. provider alanı email, google veya github gibi kayıt yöntemini tutar; böylece hoş geldin akışlarını kişinin nasıl kaydolduğuna göre yönlendirebilirsiniz.
Supabase kullanıcı kimliği birleştirme etiketi olarak kullanılamaz. Brew bu kimliği filtreleme ve segmentlere ayırma için kişi kaydında supabase_user_id olarak saklar.
Bir Supabase hesabı, pazarlama e-postası için izin anlamına gelmez. İzni kaydolma sırasında kayıt altına alın ve tanıtım amaçlı gönderimlerden önce kontrol edin.
Hayır. Supabase Auth; onay bağlantılarını, sihirli bağlantıları, davetleri ve şifre sıfırlama e-postalarını özel SMTP gibi kendi e-posta ayarları üzerinden göndermeye devam eder. Brew, bu değişiklikler auth.users tablosuna yansıdıktan sonra otomasyon başlatır. Supabase, kimlik doğrulama e-postaları ile pazarlama e-postaları için ayrı gönderim alan adları kullanılmasını önerir.
Bir olayın alınması ile e-posta gönderilmesi ayrı adımlardır. Eşleşen bir otomasyonun yayında olduğunu doğrulayın, ardından filtrelerini, çalıştırma geçmişini, alıcının uygunluğunu ve gönderim alan adını kontrol edin. E-posta adresi olmayan bir kullanıcıya ait olay (ör. henüz adres eklememiş anonim bir kullanıcı) kişi oluşturmaz ve otomasyon başlatmaz.
