Bu sayfa ErtisAuth'u production ortamında çalıştırmayı anlatır: sağlık kontrolleri, izleme, ölçekleme, veri bakımı ve bir güvenlik kontrol listesi.

Sağlık kontrolleri#

`GET /healthcheck`#

Veritabanı bağlantısını ve kurulumun yapılıp yapılmadığını kontrol eder. Anonimdir.

Durum	Kod	Gövde
Veritabanına ulaşılıyor, kurulum yapılmış	`200`	`{ "status": "Healthy" }`
Veritabanına ulaşılıyor, henüz kurulum yapılmamış	`200`	`{ "status": "Unhealthy", "message": "ErtisAuth has not been set up yet" }`
Veritabanına ulaşılamıyor	`500`	`{ "status": "Unhealthy", "message": "Health check failed" }`

Veritabanı hatasının ayrıntıları yalnızca log'a yazılır.

Not: yeni bir kurulum Unhealthy olmasına rağmen 200 döner. Orkestratörünüz yalnızca durum koduna bakıyorsa henüz kurulmamış bir instance'ı sağlıklı kabul eder; kurulumu yaparken istediğiniz de budur.

`GET /ping`#

Veritabanına dokunmadan "Pong" yanıtını verir. Bunu liveness probe, /healthcheck'i ise readiness probe olarak kullanın.

yaml

livenessProbe:
  httpGet: { path: /ping, port: 8080 }
readinessProbe:
  httpGet: { path: /healthcheck, port: 8080 }

Metrikler#

Prometheus metrikleri /metrics adresinde sunulur:

gelen HTTP istekleri: endpoint ve durum kodu başına sayılar, süreler ve devam eden istekler,
giden HTTP çağrıları (sağlayıcılara, webhook alıcılarına, mail API'lerine),
.NET runtime: bellek, garbage collection, thread pool.

/metrics kimlik doğrulaması gerektirmez. Herkese açmayın: ağınızın içinden toplayın ya da ingress'te engelleyin.

Loglama ve izleme#

ErtisAuth, standart ASP.NET Core loglaması üzerinden log yazar (varsayılan olarak konsola). Beklenmeyen hatalar stack trace'leriyle loglanır; istemci yalnızca 500 UnhandledExceptionError alır.

ApplicationInsights:ConnectionString ayarlandığında trace'ler, metrikler ve log'lar OpenTelemetry üzerinden Azure Monitor'a aktarılır (bkz. Yapılandırma).

API referansı#

Development ortamında ErtisAuth, OpenAPI dokümanını /openapi/v1.json adresinde, etkileşimli bir Scalar referansını ise /docs adresinde sunar. İkisi de diğer ortamlarda kapalıdır.

Ölçekleme#

ErtisAuth, veritabanı dışında durum tutmaz; bu yüzden bir load balancer arkasında birden fazla instance çalıştırabilirsiniz.

Önbellek#

Her instance en sık okuduğu kaynakları bellekte önbelleğe alır:

Kaynak	En fazla önbellek süresi
Membership'ler	1 saat
Kullanıcı tipleri	1 saat
Sağlayıcılar	1 saat
Roller	5 dakika
Uygulamalar	5 dakika
İptal edilmiş token'lar (yalnızca pozitif sorgular)	24 saat

Bir değişiklik, onu yapan instance'ta hemen görünür. Diğer instance'lar, önbellekteki kopyalarının süresi dolduğunda görür. Pratikte:

bir rol değişikliğinin her yerde geçerli olması 5 dakikayı bulabilir;
bir membership değişikliği (token ömürleri, mail sağlayıcıları, OTP ayarları…) 1 saati bulabilir;
iptaller her yerde hemen görülür, çünkü yalnızca iptal edilmiş token'lar önbelleğe alınır.

Bir değişikliğin hemen geçerli olması gerekiyorsa instance'ları yeniden başlatın.

Arka plan işleri#

Webhook'lar ve mail hook'lar, olayın gerçekleştiği instance'taki bellek içi kuyruklardan işlenir:

Kuyruk	Kapasite	Paralel çağrı
Webhook'lar	10.000	8
Mail'ler	10.000	4

Kuyruk dolduğunda yeni öğeler atılır ve loglanır. Kapanışta kuyruklar en fazla 30 saniye boyunca boşaltılır; bu sürenin sonunda hâlâ kuyrukta olan öğeler kaybolur. Pod'larınıza en az 30 saniyelik bir termination grace period verin.

Veritabanı#

Index'ler#

ErtisAuth ihtiyaç duyduğu index'leri başlangıçta oluşturur; bunlar arasında:

kullanıcı tiplerinin benzersiz alanları için unique index'ler; bir kullanıcı tipi her değiştiğinde eşitlenir (ve başlangıçta yeniden kontrol edilir);
arama için text index'ler;
süresi dolan verileri otomatik silen TTL index'leri: aktif token'lar, iptal edilmiş token'lar, token kodları ve tek kullanımlık şifreler süreleri dolduktan birkaç dakika sonra silinir.

Saklama süresi#

events koleksiyonu otomatik olarak temizlenmez ve her giriş ve değişiklikle büyür. Denetim kaydına ne kadar süre ihtiyacınız olduğuna karar verin ve eski olayları düzenli olarak silin; örneğin event_time üzerinde kendi TTL index'inizle:

javascript

db.events.createIndex({ event_time: 1 }, { expireAfterSeconds: 60 * 60 * 24 * 180 })

Yedekler#

ErtisAuth'un bildiği her şey MongoDB veritabanındadır. Onu her production veritabanı gibi yedekleyin ve yedekleri koruyun: parola hash'lerini, membership secret key'lerini, sağlayıcı anahtarlarını ve mail sağlayıcısı kimlik bilgilerini içerirler.

Güvenlik kontrol listesi#

ErtisAuth'u yalnızca HTTPS üzerinden sunun. Basic token'lar ve parolalar TLS bağlantısı içinde düz metin olarak taşınır.
Her membership için uzun ve rastgele bir secret_key kullanın (openssl rand -base64 48) ve gizli tutun.
Yeni membership'lerde hash algoritması olarak ARGON2ID kullanın.
Database:ConnectionString ve diğer secret'ları kaynak kontrolünün dışında tutun.
Hassas okuma yetkilerini yalnızca operatörlere verin:
- memberships.read secret key'leri ve mail kimlik bilgilerini açığa çıkarır,
- tokens.read canlı token'ları açığa çıkarır,
- events.read kullanıcı verilerini açığa çıkarır.
Her uygulamaya yalnızca ihtiyacı olanı içeren kendi rolünü verin ve uygulama secret'larını düzenli olarak yenileyin.
Herkese açık endpoint'lere gateway'inizde istek sınırı koyun: /generate-token, /verify-otp, /oauth/{slug}/login, /memberships/{m}/codes ve /memberships/{m}/codes/token. ErtisAuth istek hızını kendisi sınırlamaz.
İstemcileriniz yalnızca bilinen origin'lerdeyse CORS'u gateway'inizde kısıtlayın (ErtisAuth her origin'e izin verir).
/users/check-password isteklerinin query string'lerini loglamayın (parola taşır).
/metrics'i internete kapatın.
Sağlayıcılarda trust_email'i yalnızca ne anlama geldiğini kontrol ettikten sonra açın (bkz. Harici Kimlik Sağlayıcılar).
events koleksiyonunun saklama süresini planlayın.