Test sunucusuna yayına aldığınız kod canlı veritabanına bağlandı. Çünkü veritabanı adresi kodun içinde yazılıydı ve kimse onu değiştirmeyi hatırlamadı.
Bu yazı, yapılandırmayı koddan ayırmayı ele alıyor.
Kodun İçine Yazmanın Sorunları
- Ortama göre değiştirmek gerekir.
- Sırlar sürüm kontrolüne sızar.
- Değişiklik yeni yayın gerektirir.
- Aynı kod farklı yerlerde farklı davranır.
İkinci madde en ciddi olanıdır: veritabanı şifresi kodun içinde yazılıysa, o şifre sürüm geçmişine girer ve depoyu gören herkes tarafından okunabilir — sonradan silseniz bile geçmişte durmaya devam eder.
Bu, açık kaynağa dönüşen ya da bir yükleniciyle paylaşılan projelerde ciddi bir sızıntıdır.
Üçüncü madde ise operasyonel yavaşlık üretir. Bir zaman aşımı değerini değiştirmek için tam bir yayın süreci işletmek gereksizdir.
Temel İlke
Ayrım şu soruyla yapılır:
| Soru | Karar |
|---|---|
| Ortamlar arasında değişiyor mu? | Ortam değişkeni olmalı |
| Her ortamda aynı mı? | Kodda kalabilir |
| Gizli bilgi mi? | Kesinlikle dışarıda |
Bu ayrım pratikte şu sonucu verir: veritabanı adresi, API anahtarları, e-posta ayarları ve dış servis adresleri ortam değişkeni olur; iş mantığı sabitleri kodda kalır.
Bir vergi oranı ya da sayfa başına kayıt sayısı gibi değerler her ortamda aynıysa kodda kalabilir.
Değişkenler Nerede Tutulur?
- Sunucuda ortam dosyası. En yaygın.
- Servis tanımı içinde.
- Sır yönetim sistemi. Kurumsal.
- Konteyner yapılandırması.
Birinci seçenek çoğu VDS kurulumunda kullanılır ve iki kural gerektirir: ortam dosyası asla sürüm kontrolüne eklenmemeli ve web kökü içinde durmamalıdır.
İkinci kural sık ihlal edilir. Web kökünde duran bir yapılandırma dosyası, sunucu yanlış ayarlandığında düz metin olarak indirilebilir.
Üçüncü seçenek ise çok sunuculu ortamlarda anlamlıdır. Sırlar merkezî bir yerde tutulur ve uygulamalar çalışma anında alır.
Örnek Dosya Bırakmak
Yeni kurulumu kolaylaştıran bir alışkanlık:
- Gerçek dosya depoda olmaz.
- Örnek dosya depoda olur.
- Tüm anahtarlar örnekte listelenir.
- Değerler boş veya sahte olur.
Üçüncü madde büyük bir zaman kazandırır: örnek dosya, uygulamanın hangi ayarlara ihtiyaç duyduğunun tam listesidir — yeni bir sunucu kurarken hiçbir ayarı unutmazsınız.
Bu dosya olmadan kurulum, eksik bir değişken bulunana kadar hata veren bir deneme yanılma sürecine dönüşür.
Dördüncü madde ise güvenlik gereğidir. Örnek dosyada gerçek değer bırakmak, tüm çabayı boşa çıkarır.
Başlangıçta Doğrulama
Eksik yapılandırma erken yakalanmalıdır:
| Yaklaşım | Sonuç |
|---|---|
| Hiç kontrol etmemek | Çalışma anında beklenmedik hata |
| Varsayılan değer vermek | Sessiz yanlış davranış |
| Başlangıçta doğrulamak | Açık ve erken hata |
İkinci satır en tehlikeli olandır: eksik bir ayara sessizce varsayılan değer atamak, uygulamanın yanlış veritabanına bağlanması gibi fark edilmeyen sorunlar üretir.
Doğru yaklaşım üçüncü satırdır. Uygulama açılırken zorunlu değişkenleri kontrol eder ve eksik varsa net bir mesajla durur.
Bu, sorunun yayına alma anında görülmesini sağlar; kullanıcı bir hata bildirdiğinde değil.
Tür Dönüşümü Tuzağı
Ortam değişkenlerinin tamamı metindir:
- Sayısal değerler dönüştürülmelidir.
- Mantıksal değerler dikkat ister.
- Listeler ayrıştırılmalıdır.
İkinci madde klasik bir hata kaynağıdır: "false" metni çoğu dilde doğru olarak değerlendirilir, çünkü boş olmayan bir metindir — yani kapattığınızı sandığınız özellik açık kalır.
Bu tür değerler açıkça karşılaştırılmalı veya bir yardımcı fonksiyonla dönüştürülmelidir.
Üçüncü madde ise izin verilen alan adları gibi çoklu değerlerde ortaya çıkar. Ayırıcı karakter belirlenmeli ve boşluklar temizlenmelidir.
Güvenlik Notları
- Dosya izinlerini kısıtlayın.
- Hata sayfalarında değişkenleri göstermeyin.
- Günlüklere sır yazmayın.
- Süreç listesinde görünmesin.
İkinci madde çok yaygın bir sızıntıdır: ayrıntılı hata sayfaları bazen tüm ortam değişkenlerini ekrana basar ve veritabanı şifreniz hata mesajıyla birlikte ziyaretçiye gösterilir.
Bu nedenle üretim ortamında ayrıntılı hata gösterimi kesinlikle kapalı olmalıdır.
Dördüncü madde ise komut satırında değer geçirmenin riskini anlatır. Süreç listesini görebilen herkes o değeri okuyabilir.
Yapılandırma ve sır dosyalarının doğru izinlerle saklanması sunucu güvenliğinin temel parçasıdır; VDS kiralama sonrası ilk kurulumda dosya izinleri ve web kökü düzeni gözden geçirilmelidir.
Sonuç
Yapılandırmayı koddan ayırmanın en güçlü gerekçesi güvenliktir: kodun içine yazılan bir şifre sürüm geçmişine girer ve sonradan silseniz bile orada durmaya devam eder. Ortam dosyanızı asla depoya eklemeyin ve web kökü içinde tutmayın. Eksik ayarlara sessizce varsayılan vermek yerine başlangıçta doğrulayın — sessiz varsayılan, uygulamanın yanlış veritabanına bağlanması gibi fark edilmeyen sorunlar üretir. Ve üretimde ayrıntılı hata gösterimini kapatın; o sayfalar tüm değişkenleri ekrana basabilir.
Sıkça Sorulan Sorular (SSS)
Hangi ayarlar ortam değişkeni olmalı?
Ortamlar arasında değişen ve gizli olan her şey: veritabanı adresi, API anahtarları, e-posta ayarları ve dış servis adresleri. Her ortamda aynı olan iş mantığı sabitleri — vergi oranı, sayfa başına kayıt sayısı gibi — kodda kalabilir.
Dosyayı nereye koymalıyım?
Web kökünün dışında ve kısıtlı izinlerle. Web kökünde duran bir yapılandırma dosyası, sunucu yanlış ayarlandığında düz metin olarak indirilebilir. Ayrıca dosya asla sürüm kontrolüne eklenmemelidir; depoda yalnızca değerleri boş bir örnek dosya bulunur.
Eksik değişkeni nasıl yakalarım?
Uygulama açılırken zorunlu değişkenleri kontrol edip eksik varsa net bir mesajla durun. Sessizce varsayılan değer atamak en tehlikeli yaklaşımdır — uygulamanın yanlış veritabanına bağlanması gibi fark edilmeyen sorunlar üretir.
Kapattığım özellik neden açık kalıyor?
Ortam değişkenlerinin tamamı metindir ve "false" metni çoğu dilde doğru olarak değerlendirilir, çünkü boş olmayan bir dizedir. Mantıksal değerleri açıkça karşılaştırın veya bir yardımcı fonksiyonla dönüştürün.
