Uygulamanıza Giriş Nasıl Eklenir: Şifreler, Sihirli Bağlantılar, Google ve Roller

Bir uygulamaya giriş eklemek için bir yöntem seçin — e-posta ve şifre, sihirli bağlantılar (e-postayla gönderilen tek kullanımlık bir oturum açma bağlantısı) veya “Google ile oturum aç” — ve bunu sıfırdan yazmak yerine kanıtlanmış bir kimlik doğrulama kütüphanesi veya barındırılan bir sağlayıcıyla uygulayın. Ardından her kullanıcı türünün neler yapabileceğine karar verin (roller) ve bunu her sayfa ve API isteğinde sunucuda zorunlu kılın. Oturumlar güvenli çerezler kullanmalı, sona ermeli ve çıkış yapıldığında düzgünce bitmelidir.

Bu rehber her seçimi ve çalışan bir girişi güvenli bir girişten ayıran ayrıntıları adım adım anlatır. Arkasındaki kavramlar için kimlik doğrulama nedir rehberine bakın.

Önce karar verin: giriş gerçekten gerekli mi?

Giriş sürtünme ve sorumluluk ekler. Şu durumlarda ihtiyacınız olur:

• Kullanıcıların özel verileri varsa (rezervasyonları, belgeleri, faturaları)
• Kullanıcılar başkalarının da göreceği şeyleri değiştirebiliyorsa
• Erişim için ücret alıyorsanız
• Farklı insanların farklı izinlere ihtiyacı varsa (sahip, personel, müşteri)

Tanıtım sitesi, herkese açık bir dizin veya size yalnızca bir e-posta gönderen bir form için giriş gerekmez. Bekleme listesi hesap gerektirmez; bir e-posta alanı yeterlidir.

Yaygın dört giriş yöntemi

Birçok uygulama ikisini birleştirir: Google ile oturum açma artı e-posta sihirli bağlantıları, hiçbir şifre saklamadan çoğu insanı kapsayan popüler bir ikilidir.

E-posta ve şifre

Şifre sunuyorsanız, bunlar pazarlıksız gerekliliklerdir:

• Şifreleri yavaş bir şifre özetleme algoritmasıyla saklayın. OWASP’ın şifre saklama rehberi Argon2id önerir; alternatif olarak scrypt, bcrypt veya PBKDF2. Şifreleri asla düz metin veya hızlı genel bir özetleme ile saklamayın.
• Şifre sıfırlamaları doğrulanmış e-postaya gönderilen, rastgele, tek kullanımlık ve süreli bir bağlantı kullanır.
• Hangi e-postaların hesabı olduğunu ifşa etmeyin. “Bu e-posta kayıtlıysa bir sıfırlama bağlantısı gönderdik” demek, “Hesap bulunamadı” demekten daha iyidir.
• Giriş ve sıfırlama denemelerini hız sınırlı yapın; şifre tahminini yavaşlatmak için.
• Uzun şifrelere ve şifre yöneticilerine izin verin; belirli karakter karışımlarını zorunlu kılan kurallardan kaçının.

Sihirli bağlantılar ve tek kullanımlık kodlar

Sihirli bağlantı, kullanıcıya e-postayla gönderilen bir oturum açma bağlantısıdır. Tıklandığında kullanıcıyı oturum açmış yapar. Tek kullanımlık kod aynı fikirdir, ama tıklanmak yerine yazılır.

• Bağlantılar ve kodlar hızlı sona erer ve yalnızca bir kez çalışır.
• Bağlantı, tıklandığı cihazda kullanıcıyı oturum açmış yapmalı ve belirteç günlüklerde veya analitik araçlarında kalmamalıdır.
• Güvenilir e-posta göndermeye ihtiyacınız var — bkz. uygulamanızdan e-posta nasıl gönderilir. Gmail ve Outlook’ta test edin, spam klasörünü kontrol edin.

Google ile oturum açma (ve diğer OAuth sağlayıcıları)

“Google ile oturum aç” OAuth ve OpenID Connect kullanır: Google kullanıcının kim olduğunu onaylar ve uygulamanıza e-postasını ve adını bildirir. Eylül 2026 itibarıyla kurulum, Google Cloud Console’daki Google Auth Platform bölümünde yapılır:

1. Bir proje oluşturun veya seçin ve Marka sayfasını doldurun — kullanıcıların onay ekranında gördükleri şey (uygulama adı, destek e-postası, logo).
2. İstemciler sayfasında “Web uygulaması” türünde bir istemci oluşturun.
3. Yetkili JavaScript kaynaklarını ve yönlendirme URI’lerini ekleyin — uygulamanızın çalıştığı tam adresler ve Google’ın oturum açtıktan sonra kullanıcıları geri gönderdiği adresler.
4. İstemci kimliğini ve istemci gizli anahtarını uygulamanızın gizli bilgilerinde saklayın.

Google’ın OAuth dokümanlarına göre sık yaşanan sorunlar:

• redirect_uri_mismatch: yönlendirme adresi tam olarak eşleşmelidir; http ile https, büyük-küçük harf ve sondaki eğik çizgi dahil. Önizleme adresiniz ve canlı alan adınız için birer tane ekleyin.
• HTTPS gerekir: yönlendirme URI’leri HTTPS kullanmalıdır; geliştirme sırasında localhost hariç.
• state parametresi dönüşte siteler arası istek sahteciliğine karşı kontrol edilmelidir. İyi kütüphaneler bunu sizin için yapar.

Yalnızca temel oturum açma bilgilerini (ad, e-posta, profil) istiyorsanız Google uygulama doğrulamasının zorunlu olmadığını söyler. Kullanıcıların Gmail, Drive veya Takvim verilerine erişim istemek ise farklıdır ve doğrulama gerektirir.

Kendiniz mi inşa edersiniz, sağlayıcı mı kullanırsınız?

İlk iki seçeneğin ikisi de makuldür. Barındırılan sağlayıcılar daha çok şey üstlenir ama bir bağımlılık ekler ve bazen aktif kullanıcı başına ücret alır; güncel fiyatları kendi sitelerinden kontrol edin. Kütüphaneler her şeyi kendi veritabanınızda tutar ama doğru yapılandırmak için daha fazlası size kalır. Hangisini seçerseniz seçin, şifre veya oturum mantığını elle yazmak yerine yapay zekadan bunu kullanmasını isteyin.

Roller ve izinler

Giriş size birinin kim olduğunu söyler. İzinler ne yapabileceğini belirler. Başlangıçta basit tutun:

Rol adlarından daha önemli kurallar:

• Her seferinde sunucuda kontrol edin. Bir düğmeyi sayfada gizlemek, birinin API’yi doğrudan çağırmasını engellemez.
• Sahibe göre kapsamlandırın. “Rezervasyon 123”ü isteyen bir üye, yalnızca kendisine aitse onu almalıdır.
• Kullanıcılar kendi rollerini yükseltemez. Profil güncellemelerinde tarayıcıdan gönderilen rol alanlarını yok sayın.
• Varsayılan olarak erişim yok. Yeni rotalar, siz aksini kararlaştırmadıkça giriş gerektirmelidir.

İki hesapla test edin: birinde oturum açın, bir kaydın ID’sini not edin, sonra diğer hesapla oturum açıp o kaydı açmayı deneyin. Tam test için güvenlik kontrol listemize bakın.

Oturum güvenliği

Girişten sonra uygulama kullanıcıyı bir oturumla hatırlar — genellikle bir çerezle. OWASP’ın oturum yönetimi rehberi şunları önerir:

• Oturum çerezleri Secure (yalnızca HTTPS), HttpOnly (sayfa komut dosyaları tarafından okunamaz) ve SameSite ile ayarlanmış
• Girişte yeni bir oturum kimliği verilir ve yetkiler değiştiğinde yeniden verilir
• Sunucuda uygulanan bir boşta kalma zaman aşımı ve bir mutlak maksimum ömür
• Çıkış, yalnızca çerezi silmek yerine oturumu sunucuda sonlandırır
• Kullanıcı şifresini değiştirdiğinde oturumlar geçersiz kılınır

Giriş belirteçlerini tarayıcının localStorage alanında tutmak öğreticilerde yaygındır, ama sayfada çalışan her komut dosyasına açık hale getirir; web uygulamaları için güvenli çerezler genellikle daha iyi bir varsayılandır.

Temelleri kapsayan bir prompt

Bu uygulamaya kullanıcı hesapları ekle. Kullanıcılar e-posta ve şifreyle veya Google ile kayıt olup giriş yapabilsin. Özel kimlik doğrulama kodu yerine [kütüphane veya sağlayıcı] kullan. Şifreleri Argon2id veya bcrypt ile özetle. Şifre sıfırlamayı e-posta ile ekle; tek kullanımlık bağlantı bir saat içinde sona ersin. Oturumları güvenli, HttpOnly çerezlerde tut. /dashboard ve her /api rotasını yalnızca oturum açmış kullanıcıların kullanabileceği şekilde koru ve kullanıcılar yalnızca kendi projelerini görebilsin. Tüm kullanıcıları görebilen bir “admin” rolü ekle; /admin’e yalnızca yöneticiler ulaşabilsin, bu sunucuda kontrol edilsin.

Sonra test edin: kayıt olun, çıkış yapın, giriş yapın, şifreyi sıfırlayın, oturum kapalıyken özel bir URL’yi deneyin ve başka bir kullanıcının kaydını deneyin.

Yapay zeka ile oluşturulan girişte sık yapılan hatalar

• Korumanın yalnızca sayfada olması. Sayfa oturum açmamış kullanıcıları yönlendirir, ama API herkese veri döndürür.
• Gizli bilgilerin tarayıcıda olması. OAuth istemci gizli anahtarları ve kimlik sağlayıcısı yönetici anahtarları sunucuda kalmalıdır.
• Önizleme ve canlı URL’lerin karışması. Google’ın yönlendirme URI’si veya sıfırlama e-postasındaki bağlantı önizlemeyi gösterir; bu yüzden yayınlandıktan sonra giriş bozulur.
• E-posta doğrulaması olmaması. Herkes anyone@company.com olarak kayıt olabilir. O adrese bağlı bir şeyi vermeden önce e-postayı doğrulayın.
• Yalnızca mutlu yolu test etmek. Yanlış şifreleri, süresi dolmuş bağlantıları ve ikinci bir hesabı deneyin.

Mythex’te giriş ekleme

Mythex’te uygulamanızın kullanıcıları için giriş, uygulamanıza eklediğiniz bir şeydir — Mythex hesabınızdan ayrıdır. Mythex yerleşik bir kimlik doğrulama ürünü sunmaz; bu yüzden kendi kimlik doğrulama kütüphanenizi veya sağlayıcınızı ve anahtarlarını getirirsiniz:

1. Bir yaklaşım seçin — örneğin e-posta ve şifreyi kendi veritabanınızda saklamak veya barındırılan bir sağlayıcının SDK’sı.
2. Kullanıcıları kendiniz saklayacaksanız uygulamanın bir veritabanına ihtiyacı olur; sohbette isteyin veya /database kullanın.
3. Sağlayıcı anahtarlarını proje gizli bilgilerinde saklayın (/secrets veya proje ayarları).
4. Yukarıdakine benzer bir prompt kullanın, sonra Önizleme’de test edin. Google ile oturum açma için hem önizleme hem de yayınlanmış adresiniz için yönlendirme URI’leri ekleyin.

Dokümanlarda uygulamanıza giriş ekleme bölümüne bakın. Ücretli bir ürün inşa ediyorsanız, SaaS MVP nasıl oluşturulur rehberi hesapları ve faturalandırmayı birlikte kapsar.

Sorular