Sihrli bağlantılarla şifresiz giriş: UX ve güvenlik kontrol listesi

Sihrli bağlantı ile oturum açma nedir ve nerede yanlış gidebilir

Sihrli bağlantı, e-postanıza gönderilen tek kullanımlık bir oturum açma bağlantısıdır. Bir şifre yazmak yerine e-postayı açar, bağlantıya dokunur ve oturumunuz açılır.

Bu, insanların şifrelerden nefret ettiği, sık sık unuttuğu veya nadiren oturum açtığı ürünler için iyi bir çözüm olabilir. Ayrıca site genelinde şifre tekrarını azaltabilir, çünkü tekrar kullanılacak bir şifre yoktur. Ancak bu, güvenlik ihtiyacını ortadan kaldırmaz. Temel “anahtar”ı e-posta gelen kutunuza taşır.

Ticaretin net olması gereken tarafı: sihrli bağlantılarla şifresiz giriş, kullanıcının e-posta hesabı ve bu hesaba erişimi gizli tutabilme yeteneği kadar güvenlidir. Birisi e-postalarınızı okuyabiliyorsa genellikle sizin yerinize oturum açabilir.

Gerçekte sihrli bağlantıların en sık yanlış gittiği yollar şunlardır:

• Gelen kutusu erişimi çalınır (kimlik avı ile e-posta şifresi ele geçirilmesi, e-posta kurtarma için SIM takası, kötü amaçlı yazılım veya paylaşılan bir bilgisayarın açık bırakılması).
• Bağlantı iletilir (kasıtlı veya kazara) ve yanlış kişi kullanır.
• Kullanıcı e-postayı bir cihazda açar ama oturumu başka bir cihazda istiyordur; uygulama “yanlış” yerde açıldığında kafası karışır.
• Paylaşılan bir cihaz oturum açar ve oturum açık kalır, böylece bir sonraki kişi erişim sağlar.
• E-posta adresi yanlış yazılır ve oturum bağlantısı başkasına gider.

Küçük bir örnek: biri iş dizüstünde bir bağlantı talep eder, sonra e-postayı kişisel telefonda kontrol eder. Bağlantıya dokunur, telefon onu oturum açtırır ve dizüstünde hâlâ giriş ekranı gözükür. Akışınız ne olduğunu açıklamazsa destek talepleri gelir.

AppMaster ile yapılan bir üründe bunu inşa ediyorsanız, e-posta adımını sadece bir kolaylık değil hassas bir işlem gibi ele alın. Açık mesajlaşma, kısa ömürlü bağlantılar ve basit oturum kontrolleri deneyimi güvenli hissettirir.

Parolasız e-posta ile oturum açma ürününüz için uygun mu?

Sihrli bağlantılarla şifresiz giriş, amaç düşük sürtüşmeyle hızlı erişim sağlamaksa ve maksimum koruma değilse en iyi şekilde çalışır. Nadiren oturum açan ve şifreleri unutmaya eğilimli kullanıcılar için ve kullanıcı için zaten e-posta gelen kutusunun “ana merkez” olduğu durumlarda uygundur.

Basit bir karar yöntemi: biri yanlış hesaba girerse en kötü gerçekçi zarar nedir? Cevap “sinir bozucu ama düzeltilebilir” ise, sihrli bağlantılar iyi bir varsayılan olabilir.

Uygun örnekler genellikle şunları içerir:

• Düşük ila orta riskli uygulamalar (iç araçlar, küçük ekipler için yönetici panelleri, sınırlı izinlere sahip müşteri portalları)
• Seyrek kullanıcılar ve şifre sıfırlamalarından nefret eden ürünler
• Destek, onboarding veya onaylar gibi “hızla beni içeri al” deneyimleri
• Daha az destek bileti gerektiren erken aşama ürünler

Dikkatli olun veya sihrli bağlantıları tek giriş yöntemi olarak kullanmaktan kaçının:

• Hesapların yüksek değeri varsa (para transferleri, büyük bakiyeler, geri döndürülemez işlemler)
• Düzenlenmiş veya hassas veri saklıyorsanız (sağlık, hukuki, ayrıntılı finansal kayıtlar)
• Kullanıcılar e-posta gelen kutusunu paylaşıyorsa (paylaşılan posta kutuları, resepsiyon hesapları)
• Hedef alınma olasılığı yüksek bir kitleniz varsa (yöneticiler, yüksek ayrıcalıklı roller)

Ürününüz hassas anlara sahipse hesaplar hassas olmasa bile, giriş için e-posta kullanın; ardından riskli işlemler için ikinci faktör veya ek doğrulama gerektirin. Örneğin, ödeme bilgilerini değiştirme, veri dışa aktarma veya yeni bir yönetici ekleme gibi işlemlerde ekstra onay isteyin.

Ayrıca e-postanın ne yapabileceğine karar verin. “Sadece giriş” sihrli bağlantılar daha güvenlidir ve anlaşılması kolaydır. “Giriş + hesap kurtarma” kullanışlıdır ama e-posta erişimi olan herkesin hesabı ele geçirebilmesi anlamına gelir. E-posta adresi değişikliğini destekliyorsanız, bunu yüksek riskli bir işlem gibi ele alın.

AppMaster gibi bir no-code platformunda uygulama inşa ediyorsanız, UI basit olabilir, ancak hassas işlemler ve kurtarma politikası baştan itibaren net olmalıdır.

Temel sihrli bağlantı akışı (ve içindeki kararlar)

Sihrli bağlantılar kullanıcılara basit gelir, ama altında birçok küçük seçim yatar. Temiz bir akış insanları hareket halinde tutar ve destek taleplerini azaltır.

Kullanıcının gördüğü akış

Çoğu ürün aynı yolu izler: kullanıcı e-posta girer, bir mesaj alır, bağlantıya dokunur ve oturum açmış olur.

Yaygın bir iyileştirme, bağlantı açıldıktan sonra kısa bir onay adımı göstermektir. Bağlantı açıldığında anında oturum açmak yerine "Acme için oturumu onayla" gibi kısa bir ekran ve tek bir buton göstermek yardımcı olur. Bu, bağlantıya yanlış cihazda dokunulduğunda veya e-posta önizleme aracı tarafından açıldığında kullanışlıdır.

Mobilde “bağlantıya dokunmak” ne demek kararını verin. Yerel bir uygulamanız varsa en iyi deneyim genellikle şöyledir: bağlantıya dokun -> uygulama açılır -> oturum tamamlanır. Uygulama yüklü değilse mobil web'e geri dönün ve sonra "Uygulamayı aç" seçeneği sunun.

Vermeniz gereken kararlar

Sihirli bağlantılarla şifresiz giriş inşa etmeden önce bu kuralları kilitleyin ki deneyim öngörülebilir olsun:

• Bağlantının nerede açılacağı: uygulama içi tarayıcı, sistem tarayıcısı veya doğrudan yerel uygulama (deep link).
• Oturumun otomatik mi yoksa son bir onay ekranı mı gerektirdiği.
• Bağlantıya dokunulduğunda kullanıcı zaten oturum açmışsa ne yapacağınız.
• E-posta akış sırasında değişirse veya kullanıcı sonraki denemede farklı bir e-posta girerse ne olacağı.
• “Başarı”nın ne olduğu: son sayfaya mı yönlendirme, varsayılan ana ekrana mı, yoksa oturumu gerektiren sayfaya mı dönme.

Zaten oturum açmış durumda olmak kolayca gözden kaçırılır. Giriş yapmış bir kullanıcı yeni bir sihrli bağlantıya dokunursa (a) aynı hesapta bırakıp "Zaten oturum açtınız" gösterebilir veya (b) hesap değiştirme olarak ele alıp onay isteyebilirsiniz. AppMaster ile yapılan uygulamalarda (müşteri portalları veya dahili araçlar gibi) seçenek (a) genellikle daha güvenlidir, hesabı gerçekten değiştirme özelliğiniz yoksa.

Süre bitişi kuralları: güvenli olacak kadar kısa, çalışacak kadar uzun

Sihrli bağlantının şifresiz hissettirmesi için zahmetsiz olması gerekir. Süre bitişi bu vaadi sessizce bozabilir. Çok kısa olursa kullanıcılar gelen kutusunda süresi dolmuş bağlantılarla karşılaşır ve vazgeçer. Çok uzun olursa iletilmiş veya ifşa edilmiş bir e-posta daha büyük risk olur.

Pratik bir başlangıç noktası, sihrli bağlantılar için 10 ila 30 dakika arasında bir süre penceresidir. Daha kısa pencereler (3 ila 10 dakika) yönetici alanı erişimi veya bir ödemeyi onaylama gibi yüksek riskli işlemler için uygundur. Daha uzun pencereler (30 ila 60 dakika) düşük riskli uygulamalar için çalışabilir, ancak güçlü oturum kontrolleri ve iyi cihaz yönetimi varsa.

Süreyi e-postada ve "E-postanızı kontrol edin" ekranında açıkça belirtin. Küçük yazıyla gizlemeyin. "Bu bağlantı 15 dakika içinde süresi dolar" gibi basit ifadeler kullanın. Eğer mümkünse bekleme ekranında geri sayım gösterin, ancak kullanıcının cihaz saatine güvenmeyin.

E-posta gecikmeleri ve saat farkları yaygındır. Bazı sağlayıcılar mesajları birkaç dakika tutabilir ve bazı kullanıcılar e-postayı istek yapılan cihazdan farklı bir cihazda açar. Birkaç kural kafa karışıklığını önlemeye yardımcı olur:

• Süreyi kullanıcı saatine değil, sunucu zamanınıza göre değerlendirin.
• Eğer bağlantı tükenmek üzereyse, "Bağlantı süresi doldu. Yeni bir tane isteyin." gibi net bir mesaj gösterin.
• Bağlantı hâlâ geçerliyse ama zaten kullanıldıysa, bunu doğrudan söyleyin (ve hızlı bir sonraki adım sunun).

Bir bağlantının süresi dolduğunda en iyi deneyim, açılış sayfasından tek dokunuşla yeniden gönderme yapabilmektir. Güvenli tutun: yeniden gönderme için kısa bir soğuma süresi koyun ve bir e-posta adresinin sisteminizde kayıtlı olup olmadığını açıklamayın. Sayfa "Eğer bu e-posta kayıtlıysa, yeni bir bağlantı göndereceğiz." diyebilir.

Destek taleplerini azaltan küçük bir detay: bekleme ekranında bağlantının gönderildiği tam e-posta adresini (kısmen maskelenmiş) ve bir "E-postayı değiştir" seçeneğini gösterin. AppMaster gibi bir no-code araçta bu genellikle birkaç UI durumudur, ama "E-postayı hiç almadım" kafa karışıklığını önler.

Tek kullanımlık ve yeniden kullanım kuralları (kullanıcıların gerçekten karşılaştığı kısımlar)

Çoğu ürün için varsayılan olarak sihrli bağlantıları tek kullanımlık yapın. Bu, e-posta iletimi, paylaşılan gelen kutuları veya birinin eski bir mesajı haftalar sonra yeniden açması gibi yaygın kazalardan korur. Ayrıca destek daha basit olur: bir bağlantı kullanıldıysa iş tamamdır.

Anahtar karar "kullanıldı"nın gerçekte ne anlama geldiğidir. İnsanlar iki kez tıklayabilir, yanlış cihazda açabilir veya e-posta önizlemesinde bağlantıya dokunabilir. Kurallarınız güvenli olmalı, ama adil hissettirmelidir.

Aynı bağlantı iki kez açılırsa ne olmalı?

İyi bir temel: ilk başarılı giriş tokeni tüketir ve sonraki açılışlar "Bu bağlantı zaten kullanıldı. Yeni bir tane isteyin." gibi net bir mesaj gösterir. Belirsiz hatalardan kaçının. Sinirleri yatıştırmak için tüketmeden önce küçük bir güvenlik penceresi sunabilirsiniz; örneğin: tokeni ancak oturum oluşturulduktan sonra kullanılmış saymak.

Kullanıcı dostu ve güvenli kalacak desenler:

• Bağlantı aynı cihazda tekrar açılırsa ve kullanıcı zaten oturum açmışsa, uygulamaya yönlendirin (ve hiçbir şey göstermeyin).
• Bağlantı tekrar açılır ama aktif oturum yoksa, "Kullanıldı veya süresi doldu" + yeni bağlantı gönder düğmesi gösterin.
• Bağlantı başka bir cihazda ve daha önce kullanıldıysa, geçersiz sayın ve taze bir bağlantı isteyin.

Kullanıcılar birden çok bağlantı isterse, eski bağlantılar ölür mü?

Bunu önceden belirleyin ve tutarlı olun. En güvenli varsayılan: her yeni istek önceki bekleyen tüm bağlantıları geçersiz kılar. Bu, birisi daha sonra gelen kutusuna erişim sağlarsa zararı sınırlar.

Birden fazla bağlantıyı aynı anda geçerli tutarsanız, daha güçlü korumalar gerekir (kısa süre, sıkı tek kullanımlık kuralları ve açık cihaz/oturum kontrolleri). Aksi takdirde sihrli bağlantılar e-postada kalan uzun ömürlü erişim anahtarlarına dönüşebilir.

Tekrar tekrar çalışabilen yeniden kullanılabilir bağlantılardan kaçının. Rahat hissettirebilir ama e-postayı kalıcı bir anahtar olarak görmeye kullanıcıyı eğitir ve hesap ele geçirilmesini zor sınırlandırır.

AppMaster içinde kimlik doğrulama akışınızı kuruyorsanız, bu kuralları düz dil durumları (geçerli, kullanıldı, süresi doldu, değiştirildi) olarak yazın ki UI mesajları backend'in gerçekten uyguladığıyla eşleşsin.

Kafa karışıklığını ve destek taleplerini azaltan UX detayları

Sihirli bağlantılarla ilgili çoğu destek talebi güvenlik açığı değil. Bunlar genelde "E-postayı almadım", "Tıkladım ama hiçbir şey olmadı" veya "Bu oltalama mı?" gibidir. İyi UX bunların üçünü de önler.

Kullanıcı e-postasını gönderdikten sonra küçük bir toast yerine adanmış bir "E-postanızı kontrol edin" ekranı gösterin. Hangi adrese gönderildiğini, sonraki adımı ve gelmezse ne denemeleri gerektiğini sakin ve spesifik şekilde söyleyin.

Güçlü bir e-postanızı kontrol edin ekranı genellikle şunları içerir:

• Kullanılan tam e-posta adresi ve net bir "E-postayı değiştir" seçeneği
• Kısa bir geri sayımla yeniden gönder düğmesi (kullanıcıların spam yapmasını önlemek için)
• Tipik teslim süresi hakkında not (örneğin, "Genellikle 1 dakika içinde gelir")
• Spam, promosyonlar ve şirket filtrelerini kontrol etmeye dair nazik bir hatırlatma
• Güvenlikle ilgili kısa bir satır: "Bu bağlantıyı iletmayın"

Güven, e-postanın kendisinde kazanılır. Tutarlı bir gönderen adı ve konu satırı kullanın, içeriği öngörülebilir tutun. Kullanıcıların meşruiyeti hissetmesi için "Chrome’dan Windows üzerinde istekte bulunuldu" veya "İstek 15:42'de yapıldı" gibi bir veya iki detay ekleyin. Korkutucu metinlerden kaçının. Basit daha iyidir: "Bu bağlantı sizi oturum açtırır. Eğer siz istemediyseniz, bu e-postayı yok sayabilirsiniz."

Ayrıca en yaygın hata için plan yapın: geciken veya filtrelenen e-posta. UI kilitlenmemeli. Bağlantı biraz zaman alacaksa, kullanıcıya beklerken ne yapacağını söyleyin ve nazik bir geri dönüş sunun.

Pratik bir geri dönüş, bağlantı ile aynı e-postada kısa bir tek kullanımlık kod da eklemektir. Böylece e-posta uygulamasını yanlış cihazda açan veya e-posta güvenlik tarayıcısı nedeniyle bağlantı engellenen kullanıcılar için "Bunun yerine kod girin" seçeneği sunabilirsiniz.

Küçük ama önemli bir detay: kullanıcı eski veya zaten kullanılmış bir bağlantıya tıklarsa, yardımcı bir mesaj ve birincil net adım olarak "Bana yeni bir bağlantı gönder" gösterin; genel bir hata mesajı değil.

Arkadaşıdaki güvenlik temelleri (ağır kriptodan kaçının)

Sihrli bağlantı, arkasındaki token kadar güvenlidir. O tokeni geçici bir hesap anahtarı gibi ele alın: tahmin edilmesi zor, kısa ömürlü ve yalnızca amaçlandığı şekilde kullanılabilir olmalıdır.

Öncelikle öngörülemezlik ile başlayın. Uzun, rastgele tokenler oluşturun (e-posta, zaman veya artan ID'ler gibi şeylere dayanmasın). Mümkün olduğunca az veri saklayın. Yaygın bir desen, tokenin karma (hash) halini saklamak (böylece veritabanınız sızsa ham bağlantı yeniden kullanılamaz) ve doğrulama için yeterli metadayı tutmaktır.

Tokeni bağlama (binding) ile iletimi önleyebilirsiniz. Her zaman katı bağlama istemezsiniz (çünkü insanlar cihaz değiştirir), ama belirgin kötüye kullanımı yakalayacak hafif kontroller ekleyebilirsiniz. Örnekler: tokeni talep edilen e-posta adresine bağlamak ve isteğe bağlı olarak kaba bir parmak izi (user agent ailesi veya görülen ilk IP aralığı gibi) eklemek. Bağlam uymuyorsa, sert bir engel yerine taze bir bağlantı isteyin.

Hız sınırlama (rate limiting) gösterişli matematikten daha önemlidir. Bunun yokluğunda saldırganlar giriş formunuzu spam'leyebilir, kullanıcıları rahatsız edebilir ve e-posta adreslerinin var olup olmadığını test edebilir.

• E-posta başına ve IP başına istekleri sınırlayın (yeniden gönderimler dahil)
• E-postalar arasında kısa bir soğuma süresi ekleyin (örneğin 30–60 saniye)
• E-posta kayıtlı mı değil mi fark etmeksizin aynı mesajı gösterin
• Artışlarda uyarı verin (çok sayıda adrese çok sayıda e-posta gibi)

Son olarak, "Ben yapmadım" diyen bir kullanıcı için gerçekten ihtiyaç duyacağınız bilgileri loglayın. Bağlantı talep edildi, e-posta gönderildi, bağlantı açıldı, token kabul/red (ve nedeni) ve oturum oluşturuldu gibi olayları yakalayın. Zaman damgası, IP ve user agent dahil olsun. AppMaster ile yapılan bir araçta bu olaylar giriş iş sürecinizin parçası olarak kaydedilebilir; böylece destek ve güvenlik, sunucu içlerine bakmadan net bir iz görebilir.

Kullanıcıların anlayabileceği cihaz ve oturum yönetimi

Sihrli bağlantılar şifreleri kaldırır, ama kullanıcılar hâlâ cihazlar üzerinden düşünür: "Telefonumda oturum açtım" veya "Paylaşılan dizüstünde oturum açtım". Onlara oturumları görüp sonlandırabilecekleri basit bir yol vermezseniz, destek talepleri hızla artar.

Bir kararla başlayın: bir hesabın aynı anda kaç aktif oturumu olabilir. Çoğu tüketici ürünü için birden fazla oturum sorun olmaz (telefon + dizüstü). Hassas araçlar (yönetici panelleri, finans, iç operasyonlar) için bunu sınırlandırabilir veya yeni bir cihaz göründüğünde taze bir sihrli bağlantı isteyebilirsiniz.

Küçük bir "Cihazlar" veya "Aktif oturumlar" sayfası bunu anlamayı kolaylaştırır. Aşırı hassas olmaktansa basit ve biraz kusurlu tutun. İyi bir satır genellikle şunları içerir:

• Cihaz adı (modeli algılayamıyorsanız tarayıcı ve işletim sistemi)
• Kabataslak konum (şehir veya bölge, tam adres değil)
• Son aktif zaman
• İlk görüldüğü zaman
• Geçerli oturum için kısa bir etiket: "Bu cihaz"

Bunlardan sonra iki net eylem verin. "Oturumu kapat" sadece o oturumu sonlandırmalı. "Tüm cihazlardan çıkış yap" her şeyi sonlandırmalı, mevcut cihaz dahil ve her yerde yeniden sihrli bağlantı gerektirmelidir.

Bir cihaz kaybolduğunda veya paylaşıldığında ne olacağı konusunda karar verin. En güvenli varsayılan: çıkış yapmak tüm mevcut oturumları ve hâlâ gönderilmiş kullanılmamış bağlantıları geçersiz kılar. Kullanıcıların ayrıntılara ihtiyacı yok; sadece eski erişimin gittiği garantisine ihtiyaçları var.

Kullanıcıların şaşırmadığı basit davranış seti:

• Yeni sihrli bağlantı oturumu oluşturur
• Her oturumun boşta kalma zaman aşımı (örneğin günler) ve maksimum ömrü (örneğin haftalar) vardır
• E-posta değişikliği "tüm cihazlardan çıkış yap" tetikler
• "Tüm cihazlardan çıkış yap" bekleyen oturum bağlantılarını da iptal eder

Bunu AppMaster'da inşa ediyorsanız, oturumları Data Designer'da modele ekleyin, temel web/mobil UI'da gösterin ve İş Süreci ile tek butonlu eylemler ekleyin. Kullanıcılar, sizi güvenlik dersine sokmadan tanıdık bir "aktif oturumlar" görünümü alır.

Tehditler ve kenar durumlar: iletim, paylaşılan e-postalar ve yazım hataları

Sihrli bağlantılar basit görünür, ama e-posta karmakarışıktır. İnsanlar mesajları iletir, gelen kutularını paylaşır ve adresleri yanlış yazar. Sadece mükemmel vakaya yönelik tasarlarsanız, kafa karıştırıcı kilitlenmeler ve zor destek talepleriyle karşılaşırsınız.

İletim en büyük sürprizdir. Sihirli bağlantılarla parolasız giriş, bağlantının başkası tarafından, başka bir cihazda, dakikalar veya saatler sonra açılabileceğini varsaymalıdır. En güvenli temel, tek kullanımlık bağlantı + "bu bağlantı zaten kullanıldı" mesajı ve yeni istek düğmesiyle birlikte gitmektir. Ek koruma istiyorsanız, tıklamadan sonra yeni cihaz için hafif bir onay adımı gösterin (örneğin "Bu siz miydiniz?" ve oturumu iptal etmeye yönelik hızlı bir vazgeç seçeneği).

Paylaşılan gelen kutuları bir ürün kararı gerektirir; teknik bir yamayla çözülmez. Birden fazla kişi aynı e-postayı (ör. support@ veya sales@) okuyorsa, sihrli bağlantılar varsayılan olarak paylaşılan erişime dönüşür. Takım hesapları için ek bir adım (kişisel e-posta daveti gibi) isteyin ya da e-posta erişiminin hesap erişimi anlamına geldiğini UI'da netleştirin.

Yazım hataları "hayalet hesaplar" ve garip gizlilik sorunları yaratır. Ürününüz gerçekten bunu gerektirmiyorsa ilk oturum açmada sessizce yeni hesap oluşturmaktan kaçının. Daha güvenli yaklaşım uygulamada niyeti onaylamak ve e-posta yanıtını tarafsız tutmaktır (hesap var mı yok mu fark etmeksizin aynı mesajı gösterin).

Alias'lar da önemlidir. Plus-adreslemeyi (isim+etiket@) ve sağlayıcı alias'larını nasıl ele alacağınıza karar verin:

• E-postaları tam string olarak ele alın (daha basit, daha az sürpriz)
• Veya yaygın desenleri normalize edin (çoğaltılmış hesapları azaltır, ama istemeden kullanıcıları birleştirme riski taşır)

Destek işlerin hızlıca kötüleşebileceği yerdir. Kullanıcılardan e-postaları iletmelerini, tokenleri yapıştırmalarını veya bağlantıların ekran görüntülerini paylaşmalarını istemeyin. Bunun yerine "yeni bağlantı gönder", "diğer cihazlardan çıkış yap" ve "bu işlemi ben yapmadım" gibi basit uygulama içi eylemler sunun, böylece destek hassas verilere dokunmadan yardımcı olabilir.

Yayına almadan önce hızlı kontrol listesi

Sihirli bağlantılarla şifresiz giriş yayınlamadan önce; yavaş e-posta teslimatı, kullanıcıların bağlantıya iki kez tıklaması ve telefon ile dizüstü arasında geçiş yapma gibi dağınık gerçek dünyada ne olmasını istediğinize karar verin.

İlk olarak riski ve destek yükünü kontrol eden kuralları belirleyin. Bunları yanlış yaparsanız UI sizi kurtaramaz.

• Net bir süre penceresi belirleyin (genellikle 10–20 dakika) ve bunu e-postada ve "E-postanızı kontrol edin" ekranında gösterin.
• Bağlantıları varsayılan olarak tek kullanımlık yapın ve "kullanıldı"nın ne anlama geldiğini tanımlayın (tıklamadan sonra, başarılı oturum yaratıldıktan sonra veya ilk açılışta).
• Yeniden gönderim limitleri ve tempolama ekleyin (örneğin kısa bir soğuma), ayrıca neden tekrar "gönder" butonuna spam yapılamayacağını açıklayan nazik bir mesaj verin.
• Kullanıcı başına aktif oturumları ihtiyaç olduğunda sınırlayın ve limit dolduğunda ne olacağını belirleyin (yeni olanı tut, eskisini tut veya soru sor).
• Birden fazla tıklama ve eski bağlantıları öngörülebilir şekilde ele alın: bağlantı süresi dolduysa veya zaten kullanıldıysa, birincil eylem olarak "Yeni bir bağlantı gönder" gösterin.

Sonra kullanıcıların gerçekten gördüğü kısımları kontrol edin. Şikayetlerin çoğu belirsiz e-postalar ve kafa karıştırıcı mobil davranıştan gelir.

• E-posta içeriği: tanınabilir gönderen adı, net konu satırı, sade dil ve "Bunu istemediyseniz ne yapmalısınız" satırı.
• Mobil davranış: kullanıcı e-postayı bir cihazda açıp başka bir cihazda oturum açmak isterse ne olacağını doğrulayın ve derin bağlantıları destekleyip desteklemediğinizi netleştirin.
• Çoklu tıklamalar: kullanıcı iki kez tıklarsa korkutucu hatalardan kaçının; ya zaten oturum açtığını ya da bağlantının artık geçerli olmadığını söyleyin.
• Cihaz yönetimi: basit bir cihaz listesi, "bu cihazdan çıkış yap" seçeneği ve (varsa) zaman/cihaz/konum gibi temel denetim notları sunun.
• Kurtarma: "E-postama erişemiyorum" için bir planınız olsun (destek akışı, alternatif doğrulama veya güvenli bir hesap değişikliği süreci).

AppMaster gibi bir araçta inşa ediyorsanız, her kontrol listesini somut bir ekrana ve iş kuralına eşleyin ki davranış web ve mobil arasında tutarlı kalsın.

Gerçekçi bir örnek: yeni cihaz girişi, süresi dolmuş bağlantı ve temizleme

Maya destek ekibinde çalışıyor. Pazartesi sabahı yeni bir dizüstünde müşteri portalını açıyor. İş e-postasını giriyor ve "Bana bir giriş bağlantısı gönder"e tıklıyor. E-posta 10 dakika süresi olan bir sihrli bağlantı ile geliyor.

Bağlantıya tıklıyor, tarayıcı açılıyor ve portala giriş yapıyor. Arkada bağlantı bir kere kabul ediliyor ve sonra kullanıldı olarak işaretleniyor. Portal "Maya - Laptop Chrome" için yeni bir oturum oluşturuyor ve çıkış yapmadığı sürece onu 14 gün girişli tutuyor.

Aynı gün Maya telefonundan giriş yapmaya çalışıyor. Sabahki e-postadaki aynı bağlantıyı tekrar kullanıyor ve uygulama net bir mesaj gösteriyor: "Bu bağlantı zaten kullanıldı. Yeni bir tane isteyin." Yeni bir bağlantı istiyor ama dikkatini dağıtıyor. On beş dakika sonra tıklayınca: "Bu bağlantının süresi doldu. Yeni bir tane gönderin." diyor. Tekrar isteyip hemen tıklıyor ve telefon oturumu "Maya - iPhone Safari" olarak oluşturuluyor.

Cuma günü Maya paylaşılan ofis dizüstünde bir takım arkadaşına yardım ediyor. Oturum açıyor, işi bitiriyor, sonra "Cihazlar"a gidip "Bu cihazdan çıkış yap"a tıklıyor. Ayrılmadan önce hesabından paylaşılan dizüstü oturumunu da kaldırıyor ki bir daha kullanılamasın.

Uygulamanın takip ettiği basit kurallar:

• Bağlantılar hızlıca süresi dolar (dakikalar), ama oturumlar daha uzun sürebilir (günler)
• Her bağlantı bir kere çalışır; kullanılmış veya süresi dolmuş bağlantılar yeniden kullanılamaz
• Her oturum kullanıcı tarafından incelenebilen adlandırılmış bir cihaz oturumu oluşturur
• Kullanıcı tek bir cihazdan çıkış yapabilir veya gerekirse tüm oturumları iptal edebilir

Bunu AppMaster'da oluşturmak için kimlik doğrulama modülünden başlayın ve e-posta ile oturum açmayı etkinleştirin. Oturumları veritabanınızda saklayın (kullanıcı, cihaz adı, oluşturulma zamanı, son kullanım zamanı). Giriş e-postasını göndermek için e-posta modülünü kullanın ve token durumunu doğrulamak için (kullanılmamış, süresi dolmamış) kısa bir iş süreci oluşturun; ardından oturumları oluşturun veya iptal edin. Aşırı özel kod olmadan sihrli bağlantılarla şifresiz giriş istiyorsanız, görsel editörlerde ekranları ve mantığı kurup şimdi deneyebilirsiniz.